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PREFACE 


On  behall  of  the  Air  Force  Academy  Department 
of  Electrical  Engineering  and  the  Rocky  Mountain 
Chapter  of  the  Armed  Forces  Communication 
Electronics  Association,  welcome  to  the  1983 
Symposium  on  Military  Space  Communications 
and  Operations.  Space  is  our  newest  dimension  of 
military  operations  so  it  is  appropriate  that  this 
first  symposium  be  held  when  our  newest  service 
Academy  is  marking  the  25th  Anniversary  ol  its 
first  graduating  class. 

This  symposium  provides  a  forum  where  military 
and  industry  can  gather  to  discuss  the  latest 
developments  emerging  in  military  space  com¬ 
munications  and  operations.  We  have  created  an 
environment  that  simulates  social  and  technical  in¬ 
terchange  among  members  of  space  communica¬ 
tions  and  operations  organizations.  We  are 
honored  to  have  the  foremost  leaders  of  the 
military  and  industry  space  community  participate 
in  our  first  symposium  and  discuss  the  latest  con¬ 
cepts  in  this  newest  dimension. 

We  appreciate  your  participation  in  the  first  sym¬ 
posium  and  look  forward  to  your  continued  in¬ 
terest  in  space — "The  Newest  Dimension  of 
Military  Operations." 

Welcome  to  Colorado  Springs! 
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Satellite  Communications  Test  Aircraft 


The  AFWAL  Satellite  Communication  Test  Aircraft  is 
an  Air  Force  C- 135  (Boeing  707)  aircraft  assigned  to  the 
4950th  Test  Wing  at  Wright-Patterson  AFB,  Ohio.  The 
aircraft  is  configured  to  test  communications  satellite 
equipment  in  either  a  point-to-point  or  loop-back  mode. 

The  aircraft  is  currently  configured  to  test  the  Ah/ 
ASC-30  EHF/SHF  dual  band  Command  Post  Satcom 
Terminal.  The  ,'i/ASC-30  was  developed  by  Raytheon 
for  the  Air  Force  Wright  Aeronautical  Avionics 
Laboratory.  The  Ah/ASC-30  is  intended  for  E4-B, 
EC- 1 35,  and  other  Airborne  Command  Post  type  Air¬ 
craft  as  well  as  for  ground  fixed  and  mobile  command 
posts. 

The  Satellite  Communications  Test  Aircraft  is  avail¬ 
able  for  tours  from  4:00-6:00  p.m.  3  August  at  Peterson 
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Lt  Gen  William  J.  Hllsman,  USA 
Director 

Defense  Communications  Agency 


Lieutenant  General  William  J.  Hilsman  is  the  Director, 
Defense  Communications  Agency  (DCA).  As  Director,  General 
Hilsman  has  a  broad  range  of  responsibilities  including: 
management  and  direction  of  the  Worldwide  Defense  Com¬ 
munications  System;  system  engineering  and  technical  sup¬ 
port  to  the  Mational  Military  Command  System;  the  provision 
of  technical  support  to  the  Worldwide  Military  Command  and 
Control  (WWMCC)  System,  and  numerous  other  responsibili¬ 
ties  such  as  providing  analytical  and  automated  data  process¬ 
ing  support  to  the  Joint  Chiefs  of  Staff.  The  Director,  DCA  also 
acts  in  several  other  capacities.  As  Manager,  National  Com¬ 
munications  System,  he  is  responsible  for  providing  direction 
to  the  Worldwide  National  Communications  System,  which  in¬ 
cludes  the  communications  facilities  of  the  various  Federal 
Agencies.  In  his  capacity  as  Director,  WWMCC  System  Engi¬ 
neer,  he  is  responsible  for  providing  integration  and  technical 
guidance  for  the  implementation  of  architecture  and  technical 
evolution  of  the  Worldwide  Military  Command  and  Control 
System.  The  Director.  DCA  is  also  Chairman,  Military  Com- 
munications-Electronics  Board,  which  provides  a  liaison  point 
for  joint  and  international  communications  matters. 

Lieutenant  General  Hilsman  was  born  in  St.  Louis,  Missouri, 
on  13  March  1932.  He  graduated  from  the  United  States  Mili¬ 
tary  Academy  in  1954 and  was  commissioned  asa  second  lieu¬ 
tenant.  He  earned  a  Master's  Degree  in  Electrical  Engineering 
from  Northeastern  University,  and  is  a  graduate  of  the  Army 
Command  and  General  Staff  College  and  the  Industrial  Col¬ 
lege  of  the  Armed  Forces. 

Upon  graduation  from  the  Army  Command  and  General 
Staff  College  in  July  1966.  General  Hilsman  was  assigned  as 
Executive  Officer.  121st  Signal  Battalion,  1st  Infantry  Divi¬ 
sion,  Pacific-Vietnam. 

He  returned  to  the  United  States  in  August  1967  and  served 
as  Signal  Systems  Plans  Officer,  Office,  Assistant  Vice  Chief  of 


Staff  until  July  1 968.  In  August  1 968  he  assumed  the  duties  of 
Chief,  Research  Team,  Information  Sciences  Group,  Manage¬ 
ment  Information  Systems  Directorate,  Office,  Assistant  Vice 
Chief  of  Staff  until  July  1969. 

General  Hilsman  served  as  Commanding  Officer  of  the 
144th  Signal  Battalion.  4th  Armored  Division,  United  States 
Army,  Europe  until  February  1971,  when  he  was  selected  to  at¬ 
tend  the  Industrial  College  of  the  Armed  Forces  in  July  1971. 
Upon  graduation  from  the  Industrial  College  of  the  Armed 
Forces  in  June  1972,  General  Hilsman  was  assigned  as  Chief, 
Training  Support  Division,  later  President.  United  States  Army 
Combat  Arms  Training  Board,  and  later  Special  Assistant  to 
the  Deputy  Chief  of  Staff  for  Training  and  Schools.  United 
States  Army  Training  and  Doctrine  Command,  United  States 
Army  Infantry  Center,  Fort  Benning,  Georgia. 

In  December  1973  General  Hilsman  assumed  command  of 
the  1st  Signal  Group,  Fort  Lewis,  Washington  and  served  in 
that  position  until  reassignment  in  June  1975  to  Fort  Mon¬ 
mouth  as  Project  Manager,  Army  Tactical  Data  Systems 
(ARTADS)  and  also  provisional  commander  of  the  Army 
Communications  Research  and  Development  Command 
(CORADCOM). 

General  Hilsman  commanded  the  United  States  Army 
Signal  Center  and  Fort  Gordon  from  1977  to  1980.  He  was 
also  Commandant  of  the  United  States  Army  Signal  School. 

General  Hilsmans  decorations  include  the  Meritorious  Ser¬ 
vice  Medal,  Legion  of  Merit  with  2  Oak  Leaf  Clusters,  Bronze 
Star  Medal  with  2  Oak  Leaf  Clusters  and  the  Army  Commenda¬ 
tion  Medal  with  Oak  Leaf  Cluster. 

He  is  married  to  the  former  Emily  Jean  Butler.  They  have 
four  children. 


Panel  Member 


Lt  Gen  Lee  M.  Paschall,  USAF  (Ret.) 
President 

American  Satellite  Company 


General  Paschall  was  born  in  1922  at  Sterling,  Colorado.  He 
graduated  from  Phoenix  Union  High  School,  attended  the 
University  of  Colorado,  graduated  from  the  University  of 
Alabama  with  a  Bachelor  of  Arts  degree  in  History  (Phi  Alpha 
Theta,  Phi  Beta  Kappa)  and  graduated  from  George  Washing¬ 
ton  University  with  a  Master  of  Arts  degree  in  International  Af¬ 
fairs.  He  is  a  graduate  of  the  Infantry  Officer  Candidate  School 
and  the  Infantry  Communications  Officer  School,  Fort  Ben- 
ning,  Georgia:  Air  Command  and  Staff  College,  Communica- 
tions-Electronics  Staff  Officer  School;  and  a  distinguished 
graduate  of  the  Air  War  College,  Maxwell  Air  Force  Base, 
Alabama. 

He  rose  through  the  ranks  from  Private  to  Lieutenant 
General,  having  been  a  member  of  the  Arizona  National 
Guard,  the  Colorado  National  Guard  and  the  United  States 
Army  before  and  during  World  War  II.  Thereafter,  he  was  the 
communications  engineer  for  the  Colorado  Air  National  Guard 
until  recalled  to  active  duty  with  the  United  States  Air  Force  in 
1951.  Subsequent  assignments  included  Director  of  Opera¬ 
tions,  159th  Aircraft  Control  and  Warning  Group;  Director  of 
Operations  1815th  Airways  and  Air  Communications  Group; 
Staff  and  Faculty,  Air  University;  Chief,  Signals  Coordination 
Division.  Allied  Forces  Central  Europe  (NATO);  Office  of  Com¬ 


mercial  Communications  Management.  Air  Defer  "om- 
mand;  Defense  Commercial  Communications  Offi>  „JA; 
and  Headquarters,  Defense  Communications  Ag  He 
served  as  Commander,  United  Kingdom  Commi  -<s 

Region  (AFCS),  Deputy  Director  then  Director  of  C  J, 

Control  and  Communications,  Headquarters  United  S., .  Air 
Force  and  for  four  years  as  the  Director  of  the  Defense  Com¬ 
munications  Agency  and  Manager  of  the  National  Com¬ 
munications  System,  retiring  on  1  August  1978.  He  was  an  in¬ 
dependent  consultant  to  industry  and  government  on  telecom¬ 
munications  and  information  systems  until  assuming  his  pres¬ 
ent  position  as  President  and  Chief  Executive  Officer  of 
American  Satellite  Company  on  3  August  1981. 

General  Paschall's  decorations  include  two  Distinguished 
Service  Medals  and  the  Legion  of  Merit  with  one  oak  leaf 
cluster. 

General  Paschall  and  his  wife,  Bonnie,  reside  at  1083  Pen¬ 
sive  Lane,  Great  Falls.  Virginia,  and  their  family  consists  of 
Patricia  (Paschall)  Grillos,  her  husband  John  and  children. 
Christina  and  Stephen,  of  Belmont,  California;  Mary  and 
Stephen  Paschall  and  their  son.  Brian,  of  Boulder,  Colorado; 
and  David  Paschall  of  Annandale,  Virginia. 


m 


i  rn 


Panel  Member 


Henry  B.  Stelling,  Jr. 

Vice  President 

Requirements  Analysis  and  Programs 


Henry  B.  Stelling,  Jr.  is  Vice  President  of  Requirements  During  his  military  career,  Stelling  held  assignments  with 

Analysis  and  Programs  for  Rockwell  International  Corpora-  the  Armed  Forces  Special  Weapons  Project  at  Sandia  Base, 

tion's  Defense  Electronics  Operations  (DEO),  having  been  Mew  Mexico;  Directorate  of  Special  Weapons  at  Tactical  Air 

named  to  that  post  in  May  1980.  Command  Headquarters,  Langley  Air  Force  Base.  Virginia, 

His  responsibilities  support  strategic  business  planning  and  384th  Bombardment  Wing  of  the  Strategic  Air  Command  at 

analysis  specifically  related  to  (J.S.  and  international  re-  Little  Rock  Air  Force  Base.  Arkansas;  Air  Force  Systems  Com- 

quirements  for  defense  electronic  systems.  This  includes  an  mand  at  the  Space  and  Missile  Systems  Organization  in  Los 

assessment  of  mission  area  needs,  projected  system  vulnera-  Angeles,  California:  and  Director  of  Space  in  the  Office  of  the 

bilities,  and  alternative  system  concepts.  Deputy  Chief  of  Staff  for  Research  and  Development  at  Head- 

Currently,  Mr.  Stelling  also  has  responsibility  for  managing  quarters  (J.S.  Air  Force, 

the  payload  proposal  for  the  Space  Based  Space  Surveillance  A  native  of  San  Francisco,  Stelling  attended  the  School  of 

System.  This  effort  is  directed  toward  the  development  of  Engineering  at  the  University  of  California,  Berkeley,  where  he 

system  concepts  for  a  long  wave  infrared  prototype  capable  of  was  when  called  up  tor  active  duty  in  1943  with  the  U.S.  Army 

detecting  and  tracking  other  space  objects  at  extremely  long  Enlisted  Reserve  Corps.  In  1944,  he  entered  me  U.S.  Military 

range.  Academy,  graduating  ip  1948  with  a  bachelor  of  science 

Headquartered  in  Anaheim.  California.  DEO  is  recognized  degree  in  engineering  and  a  commission  as  a  second  lieu- 

in  the  defense  electronics  community  as  a  leader  in  guidance  tenant  in  the  U.S.  Air  Force.  While  on  active  duty,  he  subse- 

and  navigation:  command,  control,  and  communications;  and  quently  received  a  master's  degree  in  business  administration 

intelligence  programs.  DEO  is  also  developing  a  key  role  in  from  the  University  of  California,  and  a  master  of  science 

tactical  weapons  systems,  electro-optics,  shipboard  elec-  degree  in  international  affairs  from  George  Washington 

tronics  systems,  and  electronic  warfare  in  both  domestic  and  University. 

international  markets.  He  is  also  a  graduate  of  the  Armed  Forces  Staff  College  and 

Prior  to  assuming  his  post  with  Rockwell  International,  Stel-  the  Mational  War  College, 

ling  was  a  major  general  in  the  U.S.  Air  Force,  with  his  last  Stelling  is  a  member  of  Beta  Gamma  Sigma  business  ad- 

assignment  as  Vice  Commander,  Electronic  Systems  Division,  ministration  fraternity  and  a  number  of  defense  associations. 

Air  Force  Systems  Command,  Hanscom  Air  Force  Base,  He  is  active  in  commu..ity  affairs  as  a  board  member  of  the 

Massachusetts.  United  Way  of  Orange  County  Morth/South. 
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Col  Wayne  E.  Schramm,  USAF 
Director 

Information  Systems,  HQ  USAF 


Colonel  Wayne  E.  Schramm  is  the  Deputy  Director  of  Com •  his  graduation,  he  was  assigned  as  Commander  of  the  506th 

mand  and  Control,  and  Telecommunications,  in  the  office  of  Tactical  Control  Maintenance  Squadron  at  Udorn,  Thailand, 

the  Deputy  Chief  of  Staff,  Plans  and  Operations,  Headquarters  Upon  his  return  to  the  United  States  in  1969,  Col  Schramm 

United  States  Air  Force.  commanded  Det  5,  AFCS,  the  AFCS  Liaison  Office  to  ESD  at 

The  Directorate  of  Command  and  Control,  and  Telecom-  Hanscom  Air  Force  Base.  Massachusetts, 

munications  has  the  overall  responsibility  for  communications  After  attending  the  Communications-Electronics  Staff 

in  the  Air  Force,  and  is  also  the  office  of  primary  responsibility  Course  at  Keesler  Air  Force  Base,  Mississippi,  in  1971,  Col- 

for  programmatic  and  budget  activities  related  to  operational  onel  Schramm  was  assigned  to  Headquarters  United  States  Air 

command  and  control,  and  communications  systems.  Force,  Office  of  Deputy  Chief  of  Staff,  Programs  and  Re- 

Col  Schramm  was  born  in  Howard,  South  Dakota  on  3  May  sources,  where  he  worked  communications-electronics  pro- 

1936.  graduated  from  Howard  High  School  in  1954,  and  South  grams  and  communications-electronics  doctrine. 

Dakota  State  College  in  1958  with  a  Bachelor  of  Science  In  1975  Colonel  Schramm  left  the  Air  Staff  to  attend  the  Na- 

Degree  in  Engineering  Physics  and  an  Air  Force  Reserve  Of-  tional  War  College,  graduating  in  1976.  Colonel  Schramm  was 

ficer  Training  Course  Commission.  then  assigned  as  the  Vice  Commander  and  subsequently  Corn- 

Colonel  Schramm  was  first  assigned  duties  as  a  Tactical  Of-  mander  of  the  1945th  Communications  Group  at  Rhein  Main 

ficer  for  Cadets  at  Lackland  Air  Force  Base,  Texas,  and  com-  Air  Base,  Germany.  In  1979  Colonel  Schramm  returned  to  the 

pleted  the  Basic  Communications-Electronics  Course  at  Air  Staff  as  Chief  of  the  Tactical  C3,  Navigation  and  Automa- 

Keesler  Air  Force  Base,  Mississippi,  in  1959.  tion  Division  and  later  Chief  of  the  Strategic  Command,  Con- 

In  October  1959  Col  Schramm  was  assigned  to  the  Fifth  trol  and  Communications  Division  in  the  Directorate  of  Space 

TAC  in  the  Philippines,  where  he  planned  and  participated  in  Systems  and  Command,  Control  and  Communications.  Dep- 

exercise  deployments  in  Japan,  Korea.  Okinawa,  Thailand  and  uty  Chief  of  Staff,  Research,  Development  and  Acquisition, 

Taiwan.  Headquarters  United  States  Air  Force. 

Upon  returning  to  the  CONUS  in  1961,  Colonel  Schramm  In  July  1982  Colonel  Schramm  assumed  his  present  duties 

was  assigned  to  the  191 1th  Comm  Squadron  at  Offutt  Air  as  Deputy  Director  of  Command  and  Control,  and  Telecom- 

Force  Base,  Nebraska.  At  Offutt,  he  was  the  Chief  of  munications,  Deputy  Chief  of  Staff,  Plans  and  Operations, 

Maintenance  and  Comm  Operations  Officer.  Headquarters  United  States  Air  Force. 

Colonel  Schramm's  next  assignment  was  on  the  Comm  Staff  Colonel  Schramm's  military  decorations  and  awards  include 

of  Headquarters  Fifth  Air  Force,  Fuchu  Air  Force  Station,  the  Bronze  Star,  the  Meritorious  Service  Medal  with  one  Oak 

Japan,  where  he  managed  Comm  Operations  in  Korea  and  Leaf  Cluster,  and  the  Air  Force  Commendation  Medal  with  two 

Okinawa  as  well  as  Japan.  While  in  Japan  he  also  obtained  a  Oak  Leaf  Clusters. 

Master's  Degree  in  Aerospace  Management  from  the  Univer-  Colonel  Schramm  is  married  to  the  former  Jean  McClure  of 

sity  of  Southern  California.  Mobile,  Alabama,  and  has  two  children,  Susan,  19,  and  Judy, 

In  November  1967  Col  Schramm  returned  to  the  United  14.  Colonel  Schramm  was  promoted  to  the  grade  of  Colonel 

States  to  attend  Air  Command  and  Staff  College.  Following  with  a  date  of  rank  of  30  August  1977. 
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Dr.  Albert  P.  Bridges 
President 

Kaman  Sciences  Corp. 


Dr.  Bridges  has  been  President  of  Kaman  Sciences  Corpora¬ 
tion  since  August  1972  and  is  Group  Head  of  Kaman  Corpora¬ 
tion's  Science  group.  He  has  over  thirty -one  years'  experience 
in  the  management  of  high-technology  companies  and  pro¬ 
grams  as  well  as  technical  experience  covering  experimental 
investigations,  analytical  and  theoretical  studies,  and 
engineering  and  technical  activities. 

As  a  member  of  Kaman's  senior  management  team  since 
1957,  Dr.  Bridges  has  worked  extensively  in  the  areas  of  high- 
technology  management,  new  product  concepts,  systems/op¬ 
erations  analysis,  nuclear  weapons  effects,  missile  technology, 
and  inertial  distance  systems.  Throughout  the  period 
1957-1969  he  was  responsible  for  technical  direction  of  01. S. 
Navy  projects  at  Kaman  Tor  the  POLARIS  and  POSEIDON 
missile  systems. 

As  a  Project  Engineer  for  Aerophysics  Development  Cor¬ 
poration  prior  to  his  joining  Kaman,  Dr.  Bridges  was  responsi¬ 
ble  for  all  instrumentation,  flight  tests,  and  data  analyses  on 
the  flight  test  vehicle  programs.  At  Sandia  Corporation, 
Dr.  Bridges  conducted  investigations  pertaining  to  arming  and 
fuzing,  inertial  distance  systems,  new  weapons  concepts,  and 
the  energy  absorbing  characteristics  of  inelastic  solids  during 
dynamic  loading. 

Dr.  Bridges  received  his  Ph.D.  (1951)  and  M.S.  (1950) 
degrees  in  Physics  from  Vanderbilt  University  and  his  B.S. 
(1947)  in  Physics  from  the  University  of  the  South. 


Dr.  Bridges  is  a  senior  member  of  the  Institute  of  Electrical 
&  Electronics  Engineers  (IEEE),  American  Physical  Society 
(APS).  American  Association  of  Physics  Teachers  (AAPT), 
Association  of  Astronautical  Society  (AAS),  American  Phyla- 
telic  Society,  and  a  Registered  Professional  Engineer  in  the 
State  of  Colorado. 

Community  and  professional  activities  include:  1981 
1983 — Member  of  Chancellor's  Advisory  Council  for  Univer¬ 
sity  of  Colorado-Colorado  Springs;  1982— President  of  North 
End  Commercial  Association;  1981  1983— Member  of  the 
Energy,  Environment  &  Transportation  Steering  Committee 
for  the  City  of  Colorado  Springs  Chamber  of  Commerce: 
1980-1981  — Member  of  Business  Advisory  Council  for  Univer¬ 
sity  of  Colorado — Colorado  Springs;  1980-1981 — Board  of 
Director  for  North  End  Commercial  Association;  1980- 
Member  of  Governor  Richard  Lamm's  "Energy,  Environment 
&  Natural  Resources  Committee"  reviewing  the  energy  re¬ 
quirements  of  Colorado's  Front  Range  area:  1977- 1980- 
Board  of  Director  for  the  City  of  Colorado  Springs  Chamber  of 
Commerce;  1977 — Advisor  on  the  U.S.  Department  of 
Energy's  Technology  Study  Panel  for  the  Inexhaustible  Energy 
Resources  Study;  1975-1976 — Chairman  of  the  American 
Electronic  Association — Colorado  Council;  and  1974- 
1976— Director  of  the  American  Electronics  Association. 
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Maj  Gen  Winston  D.  Powers,  USAF 
DCS/Comm,  Elects  and 
Computer  Resources,  Space  Command 


Major  General  Winston  D  Powers  is  deputy  chief  of  staff, 
communications,  electronics  and  computer  resources  for  the 
(J.S.  Air  Force  Space  Command  (SPACECOM)  and  the  North 
American  Aerospace  Defense  Command  (NORAD),  chief,  Sys¬ 
tems  Integration  Office.  Space  Command:  and  commander  of 
the  Space  Communications  Division.  Air  Force  Communica¬ 
tions  Command  (AFCC).  with  consolidated  headquarters 
located  at  Peterson  Air  Force  Base.  Colo 

General  Powers  was  born  Dec  19.  1930.  and  hails  from 
Brooklyn.  N.Y.  He  has  a  bachelor  of  arts  degree  from  McKen- 
dree  College.  III.  He  attended  graduate  school  at  The  George 
Washington  University  and  completed  the  Industrial  College 
of  the  Armed  Forces. 

He  began  his  military  career  by  enlisting  in  the  U.S.  Air 
Force  in  November  1950.  His  first  assignment  was  with  the  Air 
Defense  Command  at  Hancock  Field.  N.Y.  He  entered  naviga¬ 
tor  training  at  Ellington  Air  Force  Base.  Texas,  in  September 
1952,  and  graduated  the  following  year.  He  then  had  B-29 
crew  training  at  Randolph  Air  Force  Base,  Texas,  before  an 
assignment  as  a  navigator  instructor  at  Ellington  Air  Force 
Base. 

In  May  1957  General  Powers  entered  the  Tactical  Com¬ 
munications  Officer  Training  School  at  Scott  Air  Force  Base. 
III.  After  graduation  in  June  1958,  he  was  assigned  as  com¬ 
mander  of  the  314th  Air  Division  Early  Warning  Radar  Station, 
Cheju.  Korea.  He  then  returned  to  Scott  Air  Force  Base  in  June 
1959.  for  duty  with  the  1918th  Communications  Squadron. 

Following  graduation  from  McKendree  College  in  August 
1961,  General  Powers  was  assigned  to  the  Air  Force  Com¬ 
mand  Post  at  the  Pentagon  as  a  communications  officer.  In 
July  1963  he  was  selected  to  attend  the  Communications 
Systems  Engineering  Program  of  the  American  Telephone 
and  Telegraph  Company  in  New  York  City.  After  completing 
the  AT&T  Education-With-Industry  program,  he  was  assigned 
as  communications  engineer  for  the  Defense  Communications 
Agency-United  Kingdom,  at  Croughton,  England. 

In  August  1967  the  general  was  transferred  to  the  Tactical 
Communications  Area,  Langley  Air  Force  Base,  Va.,  as  direc¬ 
tor  of  tactical  communications  operations  and  then  as  director 
of  fixed  communications  operations.  He  returned  to  a  flying 
assignment  in  July  1970.  with  the  460th  Reconnaissance  Wing 


at  Tan  Son  Nhut  Air  Base,  Republic  of  Vietnam,  flying  75  com¬ 
bat  missions  in  EC-47s. 

He  was  assigned  to  the  Organization  of  the  Joint  Chiefs  of 
Staff  in  July  1971,  as  the  Air  Force  member  of  the  Plans  and 
Policy  Division.  In  October  1973  General  Powers  was  reas¬ 
signed  to  Headquarters  U.S.  Air  Force,  Washington,  D.C.,  as 
special  assistant  for  joint  matters  in  the  Directorate  of  Com¬ 
mand.  Control  and  Communications.  Office  of  the  Deputy 
Chief  of  Staff,  Programs  and  Resources. 

General  Powers  returned  to  Korea  in  February  1974,  as  com¬ 
mander  of  the  2146th  Communications  Group  and  director  of 
communications-electronics  for  the  314th  Air  Division  at 
Osan  Air  Base.  He  returned  to  Air  Force  headquarters  in 
November  1974,  as  chief.  Plans  and  Programs  Division,  Direc¬ 
torate  of  Command,  Control  and  Communications,  where  he 
also  served  as  chairman  of  the  Command,  Control  and  Com¬ 
munications  Panel,  and  later  as  a  member  of  the  Program 
Review  Committee  of  the  Air  Staff  Board. 

The  general  became  deputy  director  of  telecommunications 
and  command  and  control  resources,  Office  of  the  Assistant 
Chief  of  Staff,  Communications  and  Computer  Resources  at 
Air  Force  headquarters  in  September  1975,  and  director  in 
June  1978.  He  was  appointed  deputy  director  of  command, 
control  and  communications  at  the  headquarters  on  July  1, 
1978.  He  assumed  his  positions  for  NORAD  in  October  1978, 
and  for  Space  Command  on  Sept.  1.  1982.  General  Powers 
became  the  first  Space  Communications  Division,  AFCC. 
commander  on  January  1.  1983. 

The  general  is  a  master  navigator  with  more  than  4,000  fly¬ 
ing  hours.  His  military  decorations  and  awards  include  the 
Legion  of  Merit,  Meritorious  Service  Medal  with  two  oak  leaf 
clusters,  Air  Medal  with  one  oak  leaf  cluster.  Air  Force  Com¬ 
mendation  Medal,  Presidential  Unit  Citation  emblem  and  the 
Outstanding  Unit  Award  ribbon.  General  Powers  was  awarded 
the  Eugene  M.  Zuckert  Award,  the  Air  Force's  top  manage¬ 
ment  award,  for  1982. 

He  was  promoted  to  major  general  July  1 .  1 98 1 .  with  date  of 
rank  Sept.  1,  1977. 

General  Powers  is  married  to  the  former  Jeanette  Wyche  of 
Brooklyn.  N.Y.  They  have  two  children:  Diane  and  David. 
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AIR  FORCE  SATELLITE  COMMUNICATIONS  (AFSATCOM)  SYSTEM 


JACK  D.  MILLER 


HEADQUARTERS  STRATEGIC  COMMUNICATIONS  DIVISION 


The  AFSATCOM  system  was  developed  to  pro¬ 
vide  secure,  reliable,  survivable,  two-way 
worldwide  record  communications  for  command 
and  control  of  strategic  forces.  The  pri¬ 
mary  mission  of  AFSATCOM  is  Emergency 
Action  Message  (EAM)  dissemination  for  the 
Single  Integrated  Operations  Plan  (SIOP) 
forces.  AFSATCOM  also  provides  for  the 
Commanders-in-Chief  (CINC)  internetting 
with  the  National  Military  Command  System, 
CINC  force  direction  and  fores  report- 
back.  In  addition  to  these  communications, 
AFSATCOM  provides  service  to  a  number  of 
high  priority  non-SIOP  users,  including 
Presidential  support. 

The  space  segment  of  the  AFSATCOM  system 
consists  of  transponders  aboard  various 
host  spacecraft.  The  FLEET  SATELLITE 
COMMUNICATIONS  (FLTSATCOM)  system  satel¬ 
lites  in  geostationary  orbits  and  the 
Satellite  Data  System  (SDS)  satellites  in 
polar  orbits  carry  the  AFSATCOM  trans¬ 
ponders.  This  system  operates  in  the 
military  Ultra-High  Frequency  (UHF)  spec¬ 
trum  225-400MHZ  and  provides  a  100  word- 
per-minute  teletype  capability.  A  certain 
degree  of  anti-jam  protection  also  has  been 
built  into  these  transponders. 

The  terminal  segment  of  AFSATCOM  consists 
of  a  family  of  modular  UHF  ground  and  air¬ 
borne  terminals.  Some  of  the  larger  ground 
terminals  have  been  installed  in  order  to 
maintain  worldwide  connectivity;  these 
terminals  are  located  at  OFFUTT  AFB ,  NE.f 
RAF  MILDENHALL,  UK.,  KADENA  AB,  JA.f  and 
EIELSON  AFB  AK.  These  terminals  are  posi¬ 
tioned  such  that  they  can  see  two  FLTSATCOM 
satellites  and  the  SDS  satellites  at  any 
one  given  time.  The  Minuteman  Launch 
Control  Centers  are  provided  with  AFSATCOM 
terminals.  The  airborne  segment  includes 
AFSATCOM  installations  in  the  E-4B,  FB-111, 
EC-135,  and  B-52G/H  models. 

The  FLTSATCOM  satellites  made  by  TRW  are 
positioned  over  CONUS,  the  Atlantic  Ocean, 
and  the  Pacific  Ocean,  and  provide  global 
coverage  from  75  degrees  North  and  South 
latitudes.  A  total  of  five  satellites  have 
been  launched  between  1978-81  with  four  re¬ 
maining  operational.  Three  more  FLTSATs 
have  been  purchased,  and  projected  launch 
dates  are  mid  to  late  1980's. 


The  SDS  satellites,  made  by  Hughes  Inc., 
provide  24  hour  polar  coverage  to  approxi¬ 
mately  40  degrees  north  latitudes. 

These  airborne  terminals,  as  well  as  selec¬ 
ted  portions  of  the  ground  terminals  have 
been  provided  with  Electromagnetic  Pulse 
(EMP)  protection.  The  space  segment  is 
also  EMP  hardened. 

The  AFSATCOM  system  remains  the  most  sur¬ 
vivable  two-way  communications  system 
deployed. 
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ABSTRACT 

Canada  apana  about  90  degrees  of 
longituda  and  haa  raquiraaanta  tor 
tactical  eg —and  and  control 
communications  aa  far  north  aa  to  at  laaat 
84  dagraaa  north  latituda.  Thaaa  facta 
craata  uni  qua  problaaa  whan  conaidaring 
raquiraaanta  for  co— unication  by 
aatallita  ralay.  Tha  trand  in  ailitary 
aatallita  coaauni cat i on  for  tactical 
purpaan  ia  towards  tha  EHF  apactrua.  For 
currently  practical  power  aperture  level a 
geoatationary  EHF  aatallita  coaaunicationa 
are  not  conai dared  likely  to  be  ailitarily 
reliable  for  a  country  with  high  latitudea 
auch  aa  Canada.  Thia  paper  examines  the 
uaa  of  inclined  elliptic  aewi -synchronous 
orbits  to  solve  this  problea.  It  is 
concluded  that  a  highly  elliptic  inclined 
Saai -synchronous  orbit  possesses 
Significant  advantages  for  EHF  tactical 
coaaunicationa  at  latitudes  coaaon  to 
ailitary  operations  in  the  Arctic.  .. 


INTRODUCTION 

Canadian  Forces  <CF )  satellite 
coaaunicationa  requireaenta  involve 
ex trees  northern  latitudea  which  cannot  be 
covered  froa  a  geoatationary  orbit.  A 
satellite  orbit  constellation  co— only 
utilized  by  both  the  USSR  and  the  US 
Depar taent  of  Defense  to  achieve  worldwide 
northern  h— i spheric  coverage  is  a  12  hour 
(period)  Molniya  orbit  constellation. 

Since  Canada,  like  the  USSR,  is  a 
country,  occupying  over  80  degrees  of 
longitude  at  a  auch  acre  northern  latitude 
than  the  USA,  it  is  considered  essential 
that  Canada  exaaine  a  Molniya  type  orbit 
for  a  Department  of  National  Defence  (DND) 
coaaunicationa  satellite  constellation. 


AIM 

•  The  ala  of  this  paper  is  to  ex— ine 
and  present  soae  of  the  considerations 
involved  in  the  utilization  of  a  Molniya 


orbital  constellation  for 
coaauni cat ions  for  the  Canadian 


satel 1 ite 
Forces. 


APPROACH 


This  paper  will  initially  present  a 
d*BcriPti°n  of  Molniya  orbits,  followed  by 
a  review  of  the  implications  of  the 

^dnl£ld!r!iitS  "ith  r**pect  to  Canadian 

?ssurr  a?!  S°“  tochnic.l 

issues  are  then  raised  on  the  dninr* 

requireaent.  with  a  Molniya  orbit  o^  th2 
user  terainals,  the  control  station,  and 
the  satellite. 


ORBITAL  CHARACTERISTICS 


A  satellite  in  a  Molniya  orbit 
characterized  by  the  orbital  para— ters 
the  following  range: 


is 

in 


i ncl i nation 

(i) 

-  63  degrees 

period 

<p> 

=11  hrs,  57  min,  46 
sec 

eccentricity 

<e> 

=  .74 

arg.  of  perigee 

<w> 

’  288.4  degrees 

right  ascension 

(Cl) 

—  dependent  upon 
Preferred  east/west 
location  of  ground 
trace. 

been  selected  for 
discussed  below. 


specific  reasons. 


Incl 1  nation. 


tiiiptical  orbits  are  characterized 

With  r^f  °f  tb*  ,ln*  of  *P«i des. 

?lrn.ith  !  Perturbation,  which  is 

earth  V  th"*  th*  «*I the 

earth,  the  major  axis  of  an  elliptical 

trajectory  will  rotate  in  the  direction  of 

motion  of  the  satellite  if  the  orbital 

inclination  is  less  than  63.4  degrees,  and 

?”!??***  to  thm  Erection  of  motion  for 
inclinations  greater  than  63.4  degree s 
Figure  1  presents  the  apsidal  rotating 
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rat*  varaus  inclination  angla  for  various 
altitude*.  Figure  2  show*  th*  valocity 
raquiraaant  par  day  nacaaaary  to  corract 
for  apaldal  rotation.  If  th*  location  of 
tha  apogaa  (or  parigaa)  of  a  gl van 
alliptical  orbit  la  daalrad  to  ba  fixed 
gaographlcal ly,  than  aithar  an  lncllnad 
orbit  cloaa  to  63.4  dagraaa  auat  b* 
sal act ad,  or  statlonkaaping  fual  will  hava 
to  ba  expanded  to  fix  th*  apogaa  (or 
parigaa)  for  non  63.4  dag ra* 

inclination*. 

Parlod. 

This  orbital  paraaatar  ia,  of  couraa, 
dapandant  upon  tha  apogaa  and  parigaa 
altitudaa  of  tha  orbit.  To  raduca  ground 
station/user  tarainal  tracking 

raquiraaant*  and  to  aak*  thaa  rapatatlv* 
(but  not  immobilize  thaa  a*  for  a 
gaoatati onary  satallita)  an  orbit  that 
glva*  an  intagral  nuabar  of  ravolutlona 
during  th*  twenty-four  hour  rotation  tla* 
of  tha  aarth  1*  aalactad.  This  ia 
nacaaaary  for  tha  satallita  ground  trac* 
to  exactly  rapaat  itsalf.  Slnca  an 
alliptical  satallita  orbit,  with  a  parlod 
that  is  lntagrally  divisible  into  24 
houra.  Mill  hava  a  tandancy  to 
gaographlcally  "hang*  ovar  a  chosan  area 
on  tha  aarth,  tha  greater  tha  satallita 
parlod,  th*  longer  th*  "hang*,  and  tha 
lass  th*  satellite  relative  notion  (and 
thus  reduced  ground  station/uaar  tarainal 
tracking  rata).  A  24  hour,  alliptical 
orbit  mm  axaalnad  in  th*  paper  "Th* 
Tundra  Orbit"  (1).  In  addition  tha  value 
of  a  "Tundra  Orbit"  was  aantianad  tha  in 
Canadian  Astronaut i ca  Llaitad  (CAL) 
Pol araat  study,  page  23,  2nd  para  (2)  and 
alluded  to  in  an  Aviation  Waek  and  Space 
Technology  article  (3).  Figura  3  ahowa  a 
typical  "Tundra*  ground  trace. 

In  th*  “Tundra  Orbit"  study,  th* 
lncllnad  alliptical  24  hour  parlod  la 
coaparad  to  th*  lncllnad  elliptical  12 
hour  parlod.  Thar*  are  advantages  and 
disadvantages  to  both  orbits,  and  thia 
paper  will  not  raaddras*  that  laau*. 

Th*  period  of  th*  aatallit*  can  also 
ba  optimized  to  raduca  th*  rotation  of  tha 
line  of  nod**.  Tha  nodal  regression  1* 
caused  by  th*  earth’s  oblatsnsss,  and  is  a 
rotation  of  tha  plan*  of  th*  trajectory 
about  th*  earth’s  axis  of  rotation  at  a 
rat*  which  depends  on  both  orbital 
Inclination  and  altitude.  For  axaspla,  th* 
successive  ground  tracks  of  posl grade 
circular  orbits  a ra  farther  to  th*  west 
than  would  ba  tha  case  due  to  aarth 
rotation  alone.  Figure  4  and  3  give  th* 
nodal  regression  rat*  versus  inclinations 
for  various  valuas  of  average  altitude. 
Figura  6  shows  tha  valocity  required  to 
aalntaln  taro  nodal  regression.  To  raduca 
this  valocity  requirement  (l.a.  station 


keeping  fual  raquiraaant) ,  a  parlod  can  b* 
aalactad  that  will  axactly  compensate  for 
this  nodal  r agression.  Both  Soviet  and 
American  satallita*  in  Molnlya  type  orbits 
have  dona  this,  and  a  parlod  similar  to  a 
typical  Soviet  Molnlya  has,  for  th* 
analysis  in  this  paper,  been  chosan. 

Eccentricity. 

Tha  selection  of  the  eccentricity 
determines  the  altitude  of  th*  apogaa  and 
parigaa  of  th*  satallita  orbit.  Th* 
graater  th*  eccentricity,  th*  more 
elongated  tha  ellipse  and  thus  th*  longer 
tha  "hang"  time  whan  th*  satallita 
approaches  apogee.  This  also  results  in 
greater  satellite  intarvlsibi 1 ity  and 
communications  between  two  widely 
separated  aarth  stalons.  It  is  also 
deslraabl*  to  choos*  a  parigaa  that  is 
above  tha  atmospheric  drag.  In  addition 
it  may  ba  deslraabl*  to  optimize  th* 
parigaa  altitude  and  orbital  path  to  and 
from  perigee,  to  a  lass  radiation 
intensive  region  of  th*  Van  Allan  bait. 

Argument  of  Parigaa. 

Th*  selection  of  this  parameter 
determine*  the  latitude  of  tha  satalllta’s 
apogaa  and  parigaa.  (i.e.  how  far 
north/south  is  apagaa/parigae?) .  It  is 
logical  for  Canada  to  place  the  apogaa  as 
far  north  as  possible  to  optlmlza  northern 
coverg*.  Thus  ana  could  axamlna  an 
argumant  of  parigaa  of  270  degrees  which 
places  tha  apogaa  at  tha  orbit’s  most 
narthmrn  location.  This  was  the  parameter 
used  in  tha  CAL  Polarsat  Study  (2),  page 
33  and  th*  "Tundra  Orbit*  Paper  (1).  It 
has  the  tremendous  advantage  of  producing 
a  ground  trace  where  satallita  motion  at 
apogaa  1*  minimal  due  to  tha  satalllta’s 
tandancy  to  "hang",  and  th*  satalllta’s 
only  movement  being  close  to  that  of  th* 
earth  rotation  rata.  As  stated  by  tha  CAL 
Polarsat  Study  (2)  page  32,  satallita 
motion  for  aithar  th*  Apogee  plus  or  minus 
2  hours  case,  or  th*  Apogaa  plus  or  minus 
4  hour*  case,  tha  satellite  motion  can 
easily  ba  handled  with  a  non-tracking 
aarth  station  antenna  at  UHF  frequencies. 
(Figures  7  and  8  show  th*  ground  traces) . 
This,  however,  would  not  b*  true  at  higher 
frequencies  (such  as  at  SHF  and  EHF)  if 
narrow  baamwldths  are  employed. 

For  th*  purposes  of  this  paper  an 
orbit  with  an  apogee  placed  further  south 
in  latitude  (38  degrees  N)  was  salactad. 
This  corresponds  to  an  argumant  of  parigaa 
of  288.4  degrees.  The  reason  for  tha 
selection  of  this  orbital  parameter  was  to 
increase  th*  east -west  coverage  across 
Canada.  The  shape  of  the  resulting  orbit, 
is  si si liar  to  that  of  th*  Soviet 
Molnlya. 
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DEGREES  PER  MEAN  SOLAR  DAT 


Right  Ascension  (  ) . 

This  parameter  Mill  pises  the 
ascending  (and  descending)  node  of  the 
orbit  st  s  given  longitude.  Consequently, 
the  longitude  plsceeent  of  the  ground 
trees  is  sffseted  by  this  psrseeter.  The 
excellent  northern  cover sge  of  the  Holnlya 
eskes  the  precise  velue  of  this  psrseeter 
not  too  criticsl  <in  teres  of  user 
tereinsl  cover sge)  for  the  northern 
heel sphere.  Fsctors  thst  Mould  need  to  be 
considered  Mould  be  orbitsl  plsceeent  to 
reduce  the  susceptibility  of  Jsselng  or 
interception  of  Canadi an  satellite 
coeeunl cat ions  uplink  and  downlink 
traffic. 

For  the  purposes  of  this  paper,  a 
right  sscensl on (  )  mss  chosen  to  optimise 
the  control  of  the  satellite  in  the  orbit 
f roe  a  single  Sround  Control  Station 
located  in  North  Bay,  Ont.  (See  figure  9 
and  table  1).  The  azlauth/elevatlon 
graticule  in  figure  10  provides  a  good 
indication  of  where  North  Bay  would  place 
the  satellite  in  the  sky.  The  selection 
of  a  right  ascension  that  is  significantly 
different  than  this  would  necessitate 
another  Sround  Control  Station  in  addition 
to  the  one  proposed  (by  this  paper)  at 
North  Bay.  The  alternative  of  a 
dependency  upon  crosslinking  betwsen 
satellites  for  satellite  control  is  not  a 
very  fault  tolerant,  or  survlvable 
alternative  with  only  one  Sround  Control 
Station.  Conversely,  if  another  Ground 
Control  Station  is  utilised  due  to 
standard  dally  operating  necessity, 
increased  survivability  Mould  be  achieved 
by  the  increased  redundancy  that  an  extra 
Sround  Control  Station  provides. 

A  different  right  ascension  could  be 
chosen,  in  order  to  place  one  of  the 
apogees  over  the  center  of  Canada,  with 
the  other  over  Siberia  (Figure  11).  One 
reason  for  this  Mould  be  to  aaxlalse  user 
teral nal  antenna  elevation  angles  over 
Canada.  The  as leuth/elevat ion  graticule  In 
Figure  12  provides  an  indication  of  the 
high  elevation  angles  obtainable  by  such  a 
right  ascension  selection.  In  strict 
teres  of  coverage,  however ,  it  is  quite 
difficult  to  obtain  the  aaxlaua  redundant 
Canadian  coverage,  with  the  usage  of  this 
specific  Holnlya  type  orbit  for 
coeeunlcatlons  between  tMo  points  within 
Canada  or  within  a  thousand  alias  or  so  of 
Canada’s  coasts.  Mith  a  4  satellite 
network,  each  satellite  will  be  used  for  a 
aaxlaua  7  hours  per  day  for  a  total 
available  usage  (and  coverage  for  points 
within  1000  alles  of  Canada’s  coasts)  of 
28  hours  per  day  for  all  4  satellites. 
If,  however,  the  apogees  are  placed  on 
opposite  sides  of  Canada  (as  chosen  by 
this  paper  and  illustrated  In  Figure  9), 
then  each  satellite  can  be  used  14  hours 


out  of  each  day.  This  results  in  56  hours 
of  total  available  usage  (and  coverage) 
for  each  day  and  gives  redundant  coverage 
equivalent  to  two  satellites  in  continuous 
use  for  nearly  all  of  Canada.  (Only 
extreee  eastern  and  western  Canadian  sites 
do  not  see  opposite  passes  for  the  full  24 
hour  day).  It  also  provides  for  a 
coeplete  northern  heel sphere  capability 
and  does  not  require  cross  linking. 


COVER ABE 


General . 


As  stated  earlier,  one  of  the  prime 
reasons  for  examining  a  Holnlya  orbit  is 
for  its  coverage  of  the  northern 
latitudes.  The  satellite  orbit  selected  in 
the  Tundra  paper  (1)  assumes  satellite  to 
satellite  relay,  or  ground  station  relay 
of  a  three  satellite  constellation. 

The  constellation  examined  by  this 
paper  is  a  four  satellite  nolnlya 
constellation  (see  figure  9).  Analysis 
has  shown  that  for  a  24  hour  day,  from 
anywhere  in  the  northern  hemisphere,  one 
of  the  for-  satellites  will  always  be  in 
view.  Thlw  provides  a  comparable  coverage 
of  the  northern  hemisphere  without  the 
requirement  to  rely  upon  satellite  to 
satellite  crossl inking.  The  operational 
concept  is  to  have  the  four  satellites 
tracing  an  identical  ground  trace,  with 
the  sub  orbital  point  of  each  satellite 
following  the  sub  orbital  trace  of  the 
previous  satellite  by  six  hours.  Thus  the 
satellites  would  be  in  four  different 
planes,  separated  by  90  degrees  in  right 
ascension.  Each  satellite  would  be  used 
for  six  hours  (3  hours  plus  or  minus  from 
apogee)  in  each  12  hour  orbit  (i.e. ,  used 
for  two  six  hour  *  periods  daily). 
Although,  the  number  of  operational 
aatellltee  in  a  Holnlya  constellation  can 
likely  be  reduced  to  two  or  three 
satellites,  the  survivability,  coverage 
and  ground  station  tracking  implications 
involved  in  this  reduced  number  of 
satellites  were  outside  the  scope  of  this 
papers  analysis. 

An  analysis  of  satellite  look  angles 
(for  the  four  satellite  constellation) 
from  various  locations  around  the  world 
raised  the  following  points: 


a.  complete  24  hours  per  day  coverage  of 
the  northern  hemisphere  is  provided! 

b.  no  satellite  tracking  is  required  for 
the  beamwidths  likely  to  be  utilised  at 
IMF  frequencies  when  all  satellites  are 
fully  operational,  (tracking  is 
required  for  SHF  and  ENF  if  a  narrow 
beamwldth  is  selected)! 
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MOLNIYA  GROUND  TRACE 
(TUNDRA  PAPER) 
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FIGURE  7«  Reference  (l) 


MOLNIYA  GROUND  TRACE 
-  POLARSAT  - 

CANADIAN  ASTRONAUTICS  LIMITED 


CANADIAN  MOLNIYA 

(Right  Ascension  Centered  on  North  Bay,  Ont.) 


FIGURE  8.  Reference  (2). 


FIGURE  9. 


CANADIAN  MOLNIYA 

(Optimized  for  Elevation  Angles  over  Canada) 
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FIGURE  11 


SINGLE  SATELLITE  POSITION  OBSERVED 


NORTH  BAY,  ONTARIO  (46.33  N,  280.S03E) 

(CANADIAN  MOLNIYA  -  Right  Ascmnsion  Cmntmrmd  on  North  Bay) 


SLANT 
RANGE  (km) 


TIME 

AZIMUTH 

ANGLE 

ELEVATION 

ANGLE 

0410 

059. 1 

7.3 

0420 

053.3 

11.3 

0520 

034.9 

20.6 

0620 

028.5 

22.0  (max.) 

027.0  (min)  21.6 
027.1  21.4 
02S.7  20.3 
032.6  19.2 
038.3  18.2 
045.7  17.1 
055.1  14.9 
067.4  8.8 
071.2  5.7 


16,531 

18,422 

28,261 

35,325 

39,421 

40,065 

42,792 

43,653 

42,688 

39,487 

34,992 

27,908 

25,774 


North  Bay  Acqulraa 


Apogaa  minus  4  hours 
Apogmm  minus  3  hours 

Apogmm  minus  2  hours 
Apogmm  minus  1  hour 
APOGEE 

Apogmm  plus  1  hour 
Apogmm  plus  2  hours 
Apogmm  plus  3  hours 
Apogmm  plus  4  hours 
North  Bay  Losms 


298.9 

6.  1 

15,993  North  Bay  Acqulrms 

303.8 

17.  1 

18,333 

315.5 

37.  1 

27,133  Apogmm  minus  4  hours 

319.5 

44.3 

33,657  Apogmm  minus  3  hours 

319.7 

(max)  45.3 

34,941 

318.8 

47.  1 

38,042  Apogmm  minus  2  hours 

315.3 

47.2  (max.) 

40,573  Apogmm  minus  1  hour 

310.5 

44.8 

41,420  APOGEE 

305.  B 

40.0 

40,645  Apogmm  plus  1  hour 

301.6 

32.9 

38,204  Apogmm  plus  2  hours 

297.4 

23.  1 

33,937  Apogmm  plus  3  hours 

291.4 

9.  1 

27,525  Apogmm  plus  4  hours 

289.9 

6.0 

26,215  North  Bay  Losms 

c.  If  on*  satel lit*  fall*,  than  24  hour 
p*r  day  cov*rag*  1*  still  provided  for 
about  93X  of  th*  northern  h**l*ph*r*, 
with  about  a  22  hour  p*r  day  cov*rag* 
for  th*  r**ainlng  3X.  During  thi* 
fallur*,  only  for  a  ll*it*d  portion  of 
th*  day,  so**  tracking  would  b* 
r*quir*d  for  UHF.  In  addition,  it 
would  b*  n*c*tiary  to  switch  th*  us*r 
t*r sinal  ground  ant*nna  ov*r  to  a 
dlff*r*nt  portion  of  th*  satellite 
orbit  (twic*  during  *ach  24  hour 
period) I  and 

d.  af t*r  a  single  satellite  failure,  it  is 

possible  to  realign  th*  satellite 
constellation  in  right  ascension  (after 
a  week  or  so  of  controlled  satellite 
drift)  to  re-permit  24  hour  per  day 
coverage  of  the  northern  hemisphere 
with  minimal  tracking  at  UHF 
frequencies.  The  decision  for  this 
manoeuvre  would  be  based  upon  remaining 
station  keeping  fuel,  and  the  time 
required  to  replace  the  failed 

satellite  with  a  new  replacement 
satel lit*. 

Of  interest  is  the  lack  of  perfect 
symmetry  of  the  east /west  Molniya  northern 
loops  when  viewed  from  a  ground  user 
terminal.  This  lack  of  symmetry  is 

evident  in  figure  lO.  In  addition,  due  to 
earth  curvature,  the  user  terminal  antenna 
at  southern  Canadian  latitudes  is  normally 
pointing  North  East  (NE)  or  North  West 
(NM)  at  a  higher  elevation  angle  than  was 
expected  (a  20  to  83  degree  mlmvmtion 
angle  was  obtained). 

Th*  high  elevation  angle  is  of 
considerable  value  when  considering  the 
power  required  to  combat  atmospheric 
losses  at  EHF  frequencies.  Figure  13 
provides  various  curves  demonstrating  th* 
Increased  amount  of  noise  at  lower 
elevation  angles,  and  figure  14  provides 
various  curves  demonstrating  the  increased 
attenuation  of  signal  due  to  lower  antenna 
elevation  angles.  Figure  12  demonstrates 
th*  very  high  elevation  angles  obtainable 
with  a  Molniya  orbit  from  a  North  Bay, 
Ontario  sit*.  Thus  it  is  readily 
apparent,  in  contrast  to  geostationary 
satellites,  a  Molniya  constellation,  with 
its  higher  antenna  elevation  angles,  will 
have  considerably  lower  losses  for  high 
latitudes  when  utilizing  th*  EHF  band. 


USER  TERMINAL  CONSIDERATIONS 
Tracking. 

A*  was  discussed  under  coverage 
considerations,  it  is  not  considered 
necessary  to  track  at  th*  beamwidth* 
likely  to  be  utilized  at  UHF  frequencies 
•dien  th*  satellite  constellation  is  100X 


operational.  However  certain  aspects  of 

th*  tracking  requirements  (or  lack  there 

of)  need  be  looked  at: 

a.  A  mobile  tactical  terminal,  such  as 

that  used  on  a  ship  or  aircraft,  must 
track  any  satellite,  whether  it  be 
geostationary  or  in  a  non-geostatl onary 
orbit.  This  is  by  virtue  of  the  fact 
that  the  platform  (ship  or  aircraft)  on 
which  the  user  terminal  is  located,  is 
in  constant  motion.  The  tracking  of  a 
non-geostatl  onary  satellite  would 
require  in  th*  user  terminal  only  a 
simple  feedback  loop  from  a 
microprocessor  that  updates  the 
satellite  position.  Orbital 

calculations,  without  perturbations, 
are  relatively  simple  and  quite 
adequate  for  tracking  purposes.  (For 
example,  a  program  for  a  TI-39  hand 
calculator  for  this  very  type  of 
calculation,  which  also  has 

perturbations  included,  has  been  don* 
(3).  It  is  likely  the  satellite  would 
have  a  beacon  onboard  (especially  for 
SHF  and  EHF)  and  once  th*  user  terminal 
acquires  th*  beacon,  it  would  follow 
the  satellite! 

b.  Since  the  danger  of  losing  a  satellite 

is  always  present,  it  would  be 
necessary  to  ensure  that  the  user 
terminals  could  still  utilize  th* 
remaining  satellites  in  th* 

constellation  for  th*  maximum  time  (in 
the  event  of  a  single  satellite 
failure).  This,  as  discussed  under 
coverage  considerations,  would  mean 
that  tracking  is  required  in  the  user 
terminals  (even  for  UHF).  In  addition, 
tracking  antennas  are  always  required 
if  low  power  large  bandwidth  signals 
are  being  handled  (otherwise  ground 
interference  can  become  intolerable). 
This  tracking  requirement  would  have 
little  impact  on  terminals  on  ships  and 
aircraft  (as  they  have  to  track 
anyway),  but  it  would  have  a  major 
Impact  upon  fixed  ground  terminals 
which  normally  do  not  track  for 
utilization  of  geostationary 

satellite*.  A  cost  analysis  needs  to 
be  don*  upon  th*  Impact  of  placing  a 
tracking  requirement  on  these  terminals 
to  evaluate  th*  added  cost  to  obtain 
complete  northern  hemispheric  coverage 
as  compared  to  about  70  degrees  north 
and  south  coverage  for  a  multiple 
geostationary  satellite  constellation! 
and 

c.  It  is  possible  that  more  than  one 
antenna  may  be  desireabl*  at  SHF  and 
EHF  frequencies  in  order  to  minimize 
th*  interuptl ve  effect  of  switching 
(and  possibly  shifting  antennas)  fro* 
one  satellite  to  another.  However,  th* 
concern  of  switching  is  a  relatively 


CANADIAN  MOLNIYA  -  LOOK  ANGLES  FROM  NORTH  BAY 
(Optimized  for  High  Elevation  Angles  over  Canada  -  see  Fig. 11) 


FIGURE  12 


AZIMUTH 

(15°  increments) 

v.s. 

ELEVATION  ANGLES 
(15°  increments) 


Attenuation  of  signal  with  frequency. 


Variation  of  noise  with  frequency 
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minor  one,  ms  many  communications 
satellites  are  periodically  interrupted 
or  operated  on  a  schedule  basis.  In 
fact,  for  very  high  latitudes,  the  need 
for  tmo  antenna  may  be  more  applicable 
to  user  terminals  that  utilize 
Beostationary  Satellites.  For  example, 
because  of  the  high  latitude,  80 
degrees  North,  the  antenna  elevation 
angle  towards  a  Telesat  Canada  Anlk 
satellite  from  Eureka,  North  West 
Territories,  is  only  1  degree,  which  is 
substantially  below  the  normally 
accepted  lower  limit  of  S  degrees.  To 
reduce  the  large  increase  In 
atmospheric  fading  of  low  elevation 
angles  (particular ly  during  the 
summer ) ,  compared  with  locations  (or 
satellites)  that  permit  high  elevation 
angles,  site  diversity  earth  stations 
are  used  at  Eureka  (7). 

DOPPLER 

An  analysis  needs  to  be  done  to 
determine  whether  the  slight  doppler  shift 
associated  with  a  Molniya  orbit  will  have 
an  Impact  upon  the  design  of  the 
spacecraft,  or  the  user  terminal.  (A 
relative  satellite  movement  of  10,000  km, 
spread  out  over  three  hours,  is  about  the 
maximum  movement  for  a  four  satellite 
constellation).  The  user  terminals  that 
would  experience  the  most  doppler  shift 
are  those  whose  location  is  roughly 
equivalent,  in  longitude,  to  the  northerly 
excursions  of  the  satellite.  (l.e.  a 
longitude  roughly  equivalent  to  the 
longitude  of  the  sub-orbital  point  of  the 
satel 1 1 te  when  at  apogee) . 

When  one  satellite  fails,  (and  it  is 
necessary  to  shift  the  direction  of  the 
user  terminal  antenna  to  the  satellites 
travelling  on  the  other  side  of  the 
northern  hemisphere)  the  doppler  shift  of 
this  "back  up"  portion  of  the  orbit  is 
minimal.  However,  for  any  time  portion  of 
the  satellite  orbit  greater  than  apogee 
plus  or  minus  three  hours,  there  would  be 
an  Increased  doppler  as  the  satellite  is 
closer  to  the  earth  and  the  satellite  is 
moving  at  a  higher  velocity. 

For  most  communications  applications 
the  doppler  shift  is  small  and  should  not 
present  major  problems.  If  it  is  required 
to  retain  synchronization  with  special 
signals,  a  doppler  error  correction 
capability  may  be  applied  to  each  user 
terminal.  It  would,  however,  complicate 
user  terminal  design  and  cost.  If  the 
doppler  error  correction  varies  for 
various  different  user  terminal  locations, 
then  a  limited  amount  of  orbital 
predictions  would  be  needed  at  the  user 
terminal  to  retain  synchronization.  It 
may  be  more  economical  to  place  the 
doppler  error  correction  onboard  the 


satellite.  This  would  necessitate  onboard 
processing  (0BP)  on  the  satellite.  A 
limited  amount  of  data  exchange 
(handshaking)  would  then  need  to  be  done 
between  the  satellite  and  the  user 
terminal  (in  order  that  the  user  teminal 
can  pass  its  unique  geographical  position 
to  the  satellite)  and  thus  have  its  unique 
dopplmr  error  correction  applied  by  the 
satellite.  The  satellite  could  also 
update  the  user  terminal  ephsmsrls  data 
each  time  this  data  exchange  takes  place. 
This  way  the  user  terminal  always  has  an 
up  to  date  ephemerls  element  set  In  case 
the  beacon  is  lost  and  the  satellite  has 
to  be  reacquired.  If  the  satellite  does 
not  have  onboard  celestial  navigation  it 
can  have  its  own  master  ephemerls  data 
updated  by  the  satellite  control  station. 
This  technique  is  commonly  employed  by 
Navigation  Satellites. 


SPACE  CRAFT  CONSIDERATIONS 
Batteries. 

A  single  space  craft  in  a  Molniya 
type  orbit  requires  considerably  less 
space  and  weight  allocated  to  batteries 
(than  that  of  the  standard  geostationary 
spacecraft)  because  it  Is  not  normally 
eclipsed  during  its  operation  periods. 
The  worst  case  eclipse  condition  for  a 
single  satellite  will  occur  near  winter 
solstice,  when  the  sun  is  in  the  southern 
hemisphere  and  casting  an  earth  shadow 
north  of  the  equator.  For  the  12  hour 
orbit,  under  the  worst  case  conditions, 
the  satellite  will  be  free  of  eclipsing 
for  4  hours  and  32  minutes  after  apogee, 
which  allows  adequate  protection,  even  for 
longer  coverage  passes.  There  is  also,  as 
with  geostationary  orbits,  the  possibility 
of  long  duration  lunar  eclipses.  These 
events  are  rare  however,  and  with  either 
three  or  four  satellites  operating  the 
lunar  eclipses  can  be  avoided.  (As  will 
be  discussed  in  a  subsequent  paragraph, 
there  is  no  requirement  to  operate  the 
spacecraft  during  an  eclipse  with  a  four 
satellite  constellation). 

The  case  examined  in  this  paper 
utilizes  the  satellite  3  hours  either  side 
of  apogee.  This  clearly  presents  no 
eclipsing  problem.  If  one  satellite 
fails,  it  may  be  necessary  to  operate  a 
satellite  at  times  in  excess  of  apogee 
plus  or  minus  4  hours,  32  minutes  (where 
eclipsing  could  occur  during  winter 
solstice).  Only  if  one  satellite  falls, 
during  the  worst  case  of  winter  solstice, 
is  there  a  possibility  that  minimal 
satellite  eclipse  operation  may  be 
necessary.  This  eclipse  operation  is  best 
avoided  by  passing  out  time  schedules  of 
°P*rstion  and  satellite  assignment 
different  than  that  for  normal 
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operation*.  The  minimal  •clips*  operation 
could  also  be  avoided  by  shifting  the 
orbit  (right  ascension)  of  Just  one  of  the 
satellites  so  that  their  planes  are  spaced 
by  90  degrees,  135  degrees,  and  135 
degrees  (or  6  hours,  9  hours,  and  9  hours 
between  satellites)  instead  of  the 
standard  90  degrees,  90  degrees,  90 
degrees  and  90  degrees  (l.e.  6  hours 
between  satellites).  Two  satellites  could 
also  have  their  orbit  shifted  (  as  was 
suggested  earlier)  so  that  the  satellite 
constellation  is  optimized  for  only  three 
satellites,  with  these  satellites  evenly 
spaced  (with  120  degrees  between  orbital 
planes  -  or  8  hours  between  satellites). 
However  these  orbital  shifts  require  days 
to  Implement,  and  necessitate  different 
tracking  orbital  parameters  for  the  user 
terminals.  Even  with  only  a  two  satellite 
constellation,  if  the  satellites  are 
phased  correctly  (90  degrees  apart  in 
right  ascension),  eclipsing  should  not  be 
a  problem. 

The  main  reason  for  the  batteries  for 
three  or  four  satellite  constellations 
would  be  for  the  limited  satellite 
housekeeping  and  operation  during  the 
initial  satellite  deployment  (before  the 
solar  cells  can  be  deployed  to  provide 
power).  Assuming  that  the  spacecraft  is 
shut  down  during  its  eclipse  and 
close— to— the  earth  southern  hemisphere 
perigee  orbital  path  portion,  battery 
power  may  be  required  only  for  autonomous 
(housekeeping)  operation  of  the 
spacecraft.  It  will  likely  be  necessary 
to  provide  power  to  a  limited  number  of 
critical  housekeeping  functions  during  the 
eclipsed  portion  of  the  southern  pass  (in 
particular  the  coeeand  receiver).  However 
it  should  be  noted  there  is  no  requirement 
to  utilize  the  spacecraft  as  a  satellite 
communications  relay  during  this  portion 
of  its  orbit.  As  batteries  consist  of 
•bout  10X  of  the  spacecraft  dry  weight,  a 
reduction  of  SOX  (arbitrarily  chosen  for 
illustrative  purposes)  in  the  required 
batteries,  would  reduce  the  spacecraft  dry 
weight  by  about  5X.  This  would  bring 
about  a  reduction  in  this  aspect  of 
spacecraft  cost. 

Radiation  Protection 

A  Holniya  type  orbit  will  pass 
through  the  Van  Allen  belt  twice  every 
twelve  hours.  Inclined  elliptical  orbits 
(such  as  the  Holniya),  pass  through 
varying  regions  of  radiation  intensity, 
and  detailed  analysis  must  be  performed  on 
each  specific  orbital  case.  "In  general, 
however,  inclined  orbit*  intercept  less  of 
the  Intense  radiation  field,  and  highly 
elliptic  orbits  can  be  designed  to  spend  a 
comparatively  short  period  of  time  in  the 
region*  of  intense  radiation..."  (2). 


The  solar  arrays  are  likely  to  be  the 
satellite  component  most  affected  by  Van 
Allen  belt  radiation.  It  is  not  certain 
if  the  type  of  stabilization  of  the 
spacecraft  (and  consequently  the  position 
of  the  solar  arrays)  is  of  major 
Importance  when  repeatedly  encountering 
the  Van  Allen  belt. 

While  a  three  axis  spacecraft  is  in 
9Sn*r*i  capable  of  generating  more  solar 
power  than  a  spin  stabilized  spacecraft, 
it  is  not  clear  if  the  orientation  of  the 
solar  arrays  of  a  three  axis  spacecraft 
may  make  it  more  vulnerable  to  radiation 
bmflradation  than  a  spinner.  The 

consideration  here  is  that  the  spinning 
movement  of  the  spin  stabilized  spacecraft 
arrays  would  distribute  the  radiation 
damage  received  during  spacecraft 
transition  through  the  magnetosphere.  A 
counter  to  this  statement  is  that  a  larger 
solar  array  could  be  used  on  the  three 
axis  spacecraft  to  compensate,  and  thus 
Increase  the  power  available  at 
•nd-of-life.  Another  concept  is  that  since 
the  spacecraft  is  eclipsed  during  the 
southern  hemisphere  pass  (and  transition 
through  the  magnetosphere) ,  the  solar 
arrays  of  a  three  axis  spacecraft  could  be 
temporarily  reorientated  for  the 
magnetosphere  pass  to  minimize  radiation 
degradation.  However  this  re-or ientatlon 
concept  may  be  too  complex  and  costly  to 
•aka  it*  utilization  worthwhile.  In 
addition,  if  a  military  spacecraft  is 
properly  hardened,  it  is  likely  that  the 
radiation  from  the  Van  Allen  belt  need  not 
be  of  major  concern  (and  thus  the  choice 
of  stabilization  method  not  affected  by 
radiation  considerations). 

If  military  radiation  hardening  is 
applied  to  the  satellite,  the  effect  of 
the  magnetosphere  upon  the  satellite  is 
minimized  and  it  is  quite  possible  that 
satellite  life  comparable  to  that  of 
geostationary  satellite*  can  be  obtained. 
Of  course  the  entire  concern  with  respect 
to  solar  array  degradation  could  be 
eliminated  through  the  use  of  a  nuclear 
power  supply. 


Apogee  Kick  Motor  and  Launch  Requirements 

The  apogee  kick  motor  is  normally 
utilized  to  perform  the  combined 
inclination  change  and  circular  orbit 
injection  manoeuvre.  For  a  Holniya  type 
orbit  the  energy  required  here  is 
considerably  less  than  that  for  a 
geostationary  orbit.  As  a  rule  of  thumb 
the  energy  required  to  place  a  satellite 
in  a  Holniya  type  orbit  is  approximately 
equivalent  to  that  required  to  place  a 
utzHlt*  in  a  Hohmann  transfer  orbit  for 
a  geostationary  orbital  slot.  In  general , 
•  high  latitude  launch  site,  such  as 


Churchill,  Manitoba,  (or,  on  tha  eastern 
uaboard,  East  Quoddy) ,  launchars  with  1/3 
tha  boost  capability  can  ba  usad  to  launch 
Molniya  satal litas  as  coaparad  that  for 
gaostationary  satal litas.  In  addition  tha 
inclination  changa  required  to  ba 
performed  by  tha  apogaa  kick  motor  would 
dap and  upon  tha  launch  latituda  and 
azimuth  (tha  launch  sita  sa-faty  arcs),  and 
tha  inclination  iapartad  by  tha  launch 
booster .  This  energy  can  ba  ainlaizad  by 
careful  launch  window  selection. 

In  general,  this  paper’s  12  hour 
inclined  elliptic  orbit  could  ba  achieved 
by  a  spacecraft  with  a  considerably  lass 
powerful  apogaa  kick  eotor  than  that 
raquirad  by  tha  standard  gaostationary 
satellite.  Dependant  upon  tha  payload 
weight,  auch  of  tha  energy  requireeent 
could  ba  p erf oread  by  tha  booster, 
mini sizing  tha  size  of  tha  apogaa  kick 
eotor.  As  tha  apogee  kick  aotor  takas  up 
approx leataly  SOX  of  tha  satellite’s  eass, 
this  would  aaan  a  substantial  weight  and 
cost  saving.  A  rastartabla  motor  is, 
however,  still  raquirad  for  orbit 
stabilization  and  periodic  orbit 
correction.  A  trade-off  study  on  tha 
apogaa  kick  motor  requirement  would  need 
further  examine  if  most  of  tha  orbital 
stabi 1 lzatlon  and  correction  could  ba  dona 
by  tha  spacecraft’s  attitude  control 
system  (ACS)  thrusters. 


Survlvabl 1 lty 

4  ,  _  •P^ecraft  constellation  in  an 

inclined  elliptical  orbit  is  a  varv 
constellation.  Since  mmoh 
satellite  is  in  a  separata  orbital  plana 
a  separate  antisatel 1 i te  (ASAT)  device 
would  be  raquirad  to  attack  each  Molniya 
In  addition  currant  ASAT 
technology  would  permit  tha  attack  of  tha 
satellite  only  during  its  relatively  low 
(southern  haml sphere)  altitude  pass.  The 
Molniya  satellite  perigee  altitude  can  be 
easily  and  substantially  altered  by  a  very 
slight  energy  expenditure  at  apogee.  This 
capability  (to  vary  perigee  parameters)  is 
an  effective  ASAT  counter-measure  if  there 
is  an  advance  warning  of  an  impending 
attack  and  would  greatly  complicate  the 
tracking  and  targetting  necessary  for  a 
successful  ASAT  negation. 


Conceptually,  upon  receiving  warning, 
the  satellite’s  orbit  could  be  altered  by 
an  energy  thrust  at  apogee  sufficient  to 
cause  the  ASAT  attack  to  be  unsuccessful. 
As  the  largest  change  in  this  defensive 
orbit  shift  takes  place  at  perigee,  it 
would  not  significantly  degrade  the 
satellite’s  communications  capability.  The 
orbit  could  be  easily  rs-ad justed,  after 
attack,  to  its  previous  position.  The 
warning  received  could  be  from  external 


intelligence  sources,  or  even  from 
autonomous  sensors  onboard  the  Canadian 
Molniya  satellite.  The  degree  of  response 
to  a  threat  could  be  controlled  from  the 
Qround  Control  Station,  or  preprogrammed 
**  part  of  the  autonomous  satellite 
operation  package. 

Survivability  could  be  enhanced  by 
multiple  Control  Stations  (although  as 
discussed,  only  one  at  North  Bay  is 
n*cmssary  to  achieve  the  required 
coverage) .  Crosslinking  between 

satellites  (in  addition  to  multiple 
Control  Stations),  would  also  enhance 
survivability,  as  the  loss  of  one  Control 
Station  (and  its  coverage  area)  would  not 
*ffmct  the  satellite  constellation 
operation.  Redundant  control  would  be 
provided  by  one  of  the  multiple  Control 
Stations,  and  the  spacecraft  crosslinking 
would  ensure  the  appropriate  coverage  is 
obtained. 

Autonomous  operation  is  required  for 
the  inclined  elliptic  spacecraft  to  ensure 
the  basic  minimum  of  housekeeping 
functions  are  perforeed  during  the 
southern  hemispheric  pass.  The  autonomous 
requirement  could  also  impact  upon  the 
smlmctian  of  the  stabilization  method 
(three  axis  compared  to  spin  stabilized). 
It  is  noted  that  autonomous  operation  is  a 
military  requirement  in  any  case, 
rtgtrdlMf  of  the  orbit  selected,  to 
obviate  outages  caused  by  failure  of  the 
satellite  Bround  Control  Station. 


CANADIAN  LAUNCH 

One  aspect  that  need  be  considered  is 
that  the  selection  of  a  Molniya  orbit 
retains  the  option  for  a  Canadian  launch 
iQMtiM  in  the  future.  A  geostationary 
■stellite  would  be  very  energy  expensive 
to  launch  (from  Canada)  due  to  the  large 
Inclination  change  required.  A  Molniya 
satellite  with  a  63.4  degree  inclination 
launched  from  Churchill,  Manitoba  (38 
degrees,  44  minutes  North)  would  have  only 
«  3  degree  inclination  change  required 
(for  an  easterly  launch).  This  small 
required  inclination  change,  coupled  with 
the  lighter  weight  requirements  of  the 
Molniya  (less  batteries,  and  a  very  small, 
or  no,  apogee  kick  motor)  makes  a  Canadian 
launch  a  technically  feasible  and  possibly 
•^tractive  option.  Bristol  Aeorospace  has 
done  a  preliminary  study  into  the  cost 
♦~-»Mlity  of  a  Canadian  Launch  Vehicle 

If  a  Molniya  satellite  were  launched 
from  Churchill,  it  could  conceivably  be 
placed  directly  into  the  required  orbital 
ellipse  (with  a  perigee  of  616  Km  and  an 
apogee  of  39,770  Km)  at  an  inclination  of 
about  59  degrees.  The  line  of  apsides 
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would  be  permitted  to  rotate  until  the 
■pogM  is  in  the  corract  orbital 
position.  At  this  time  ths  saall  apogee 
kick  aotor  (or  ths  ACS  thrustars)  would  ba 
f i rad  to  aaka  tha  slight  5  dagraa 
inclination  changa  and  ainiaiza  tha 
apsidal  rotation  <A  characteristic  erf  63.4 
dagraa  inclinations).  When  tha  raquirad 
nodal  rotation  has  taken  place  to  parait 
tha  correct  right  ascension  to  be  achieved 
a  final  firing  of  station keeping  thrustars 
would  ainiaiza  tha  nodal  rotation  and  fix 
tha  satellite  in  its  corract  orbit.  In 
addition,  dependant  upon  tha  Canadian 
launch  window,  and  other  factors,  various 
other  sequences  could  ba  followed  to  place 
tha  satellite  in  orbit.  A  siallar  launch 
to  orbit  concept  could  be  followed  by  a 
launch  froa  East  Ouoddy. 

Dependent  upon  the  size  of  the 
required  inclination  change,  and  the 
energy  and  guidance  precision  in  tha 
launch  booster,  it  is  possible  that  an 
apogee  kick  aotor  is  not  required  at  all 
(for  a  Canadian  launch).  The  requlreaent 
for  the  apogee  kick  aotor  would  need  to  be 
exaalned  further  in  ter as  of  survivability 
requireaents  (excess  energy  for  ASAT 
avoidance  aanoeuvres) ,  launch  site 
latitude,  launch  site  safety  arcs,  launch 
booster  capability,  and  required  station 
keeping  fuel  for  aaxlaua  satellite  life. 

Econoaic,  political,  and  ailitary 
security  aatters  need  be  exaalned  in 
detail  whan  considering  a  Canadian 
launch.  The  technical  expertise  of 
various  Canadian  flras  (such  as,  for 
exaaple,  Bristol  Aerospace  (saall  apogee 
kick  aotors  and  boosters)  and  Litton 
(guidance  coaputers) )  could  be  greatly 
enhanced  by  such  a  project. 


CONCLUSION 


polar  coverage  and  increased  elevation 
angles  (for  northern  utilization  of 
EHF/SHF)  impossible  to  attain  with  a 
geostationary  deployaent. 
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CF  satellite  communications 

requireaents  could  be  satisfied  by  an 
Inclined  elliptic  two  satellite 

constellation  in  an  orbit  similar  to  the 
Soviet  Molniya  satellites.  Worldwide 

northern  hemispheric  coverage  (including 
all  of  the  northern  polar  region),  coupled 
with  completely  redundant  Canadian 
coverage  (in  the  event  of  a  single 
satellite  failure)  can  be  obtained  by  a 
three  or  a  four  satellite  orbit 

constellation  selection.  Initial 

indications  are  that  the  cost  impact  on 

user  terminals  will  not  be  significantly 
|  greater  (for  inclined  elliptic  orbits) 

I  than  those  designed  for  geostationary 

satellite  use,  and  the  costs  for  the 
satellite  and  the  launch  booster  are 
likely  to  bo  substantially  less  than  those 
for  Si  geostationary  satellite.  In 
addition  the  selection  of  a  Molniya  type 
orbit  provides  tha  required  operational 
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j  ABSTRACT 

The  trend  in  military  space  ground  system 
architecture  is  toward  larger  amounts  of  software 
and  more  widely  distributed  processors.  At  the 
same  time,  life  cycle  cost  considerations  dictate 
that  fewer  personnel  with  minimized  skill  levels 
and  knowledge  operate  and  support  these  systems. 
This r*squeeze*' necessitates  more  human  engineer¬ 
ing  and  operational  planning  into  the  design  of 
these  systems.  Several  techniques  have  been 
developed  to  satisfy  these  requirements.  An 
operations  language  is  one  of  these  techniques. 
It  involves  a  specially  defined  syntax  for  con¬ 
trol  of  the  system.  Individual  directives  are 
able  to  be  grouped  into  operations  language  pro¬ 
cedures.  These  procedures  can  be  prepared  off¬ 
line  ahead  of  time  by  more  skilled  personnel  and 
then  used  to  ensure  repeatability  of  operational 
sequences  and  reduce  operator  errors.  The  use  of 
an  operations  language  also  provides  benefits  for 
the  handling  of  contingency  operations  as  well  as 
in  the  system  testing  and  validation  programs^ 


I .  BACKGROUND 


The  concept  of  an  operations  language  has  evolved 
over  the  past  years  due  to  several  factors. 
First  and  foremost,  it  was  recognized  that  the 
operation  of  spacecraft  ground  systems  involved 
performing  sequences  of  activities  that  were 
either  1)  repeated  frequently;  such  as  housekeep¬ 
ing  during  every  spacecraft  pass,  routine  commu¬ 
nications  switching;  or  2)  were  not  exercised 
often,  but  when  required  had  little  room  for 
error;  such  as  spacecraft  contingency  opera¬ 
tions.  Second,  a  need  to  standardize  input 
techniques  developed,  since  different  subsystem 
elements  often  employed  different  techniques  of 
manual  Input  Implementation. 

These  reasons  drove  system  developers  to  a 
standardized  syntax  for  affecting  manual  control 
over  a  system.  The  resulting  syntax  inputs  were 
then  used  by  the  operations  personnel  during 
planning  and  subsequent  real-time  operations.  It 
was  realized  that  the  ability  to  group  and  pre¬ 
order  these  syntax  Inputs  provided  a  real  benefit 
In  terms  of  being  able  to  exercise  "canned" 
sequences  of  operations  for  both  normal  and 
contingency  conditions. 


This  concept  is  not  unique  to  any  specific 
system;  some  of  these  ideas  have  surfaced 
independently  in  various  spacecraft  ground 
systems.  While  not  unique,  the  establishment  of 
an  operations  language  as  a  systems  engineering 
entity  has  been  given  special  treatment  by  OAO 
Corporation  over  the  past  years,  starting  in  the 
civilian  space  program  and  migrating  to  the  mili¬ 
tary  space  arena. 

The  evolution  of  an  operations  language  is 
illustrated  in  figure  1.  At  NASA's  Goddard  Space 
Flight  Center,  the  use  of  procedures  originated 
with  the  following  spacecraft  missions:  Applica¬ 
tions  Technology  Satellite-F  (ATS-F),  Orbiting 
Solar  Observatory  (0S0),  Atmospheric  Explorer 
(AE),  the  TIROS-N  weather  satellite,  and  the 
International  Ultraviolet  Explorer  (IUE).  These 
missions  used  pnmative  forms  of  operations 
languages  with  acronyms  such  as  ASP,  ATLAS,  PCL 
and  CCL.  From  the  various  experiences  with  these 
ground  system  operations  languages,  a  study  was 
initiated  to  combine  these  approaches  into  a 
single  standardized  language.  This  study 
resulted  in  development  of  the  System  Test  and 
Operations  Language  (STOL).  STOL  gleaned  the 
best  features  from  the  predecessor  languages  and 
discarded  the  hinderances.  STOL  has  now  become 
the  Goddard  Space  Flight  Center  (GSFC)  standard 
for  both  control  centers  and  spacecraft  integra¬ 
tion  and  test  operations  for  the  1980’s. 
Missions  using  STOL  are  the  Solar  Maximum  Mission 
(SMM),  LANDSAT-D,  SPACELAB,  Space  Telescope,  the 
Multi-Satellite  Operations  Control  Center,  and 
all  Modular  Mission  Spacecraft  (MMS)  deriva¬ 
tives.  OAO  Corporation  participated  in  the 
development  of  STOL  and  provided  the  first  STOL 
implementation  for  the  SMM  Integration  and  Test 
system  at  GSFC.  Subsequently,  OAO  has  imple¬ 
mented  STOL  for  other  NASA  missions  and  has 
taught  STOL  operations  and  implerentation  to 
Industry.  This  concept  of  an  operations  language 
has  been  transfered  to  the  military  space  ground 
system  environment  via  the  Global  Positioning 
System  (GPS)  mission  and  has  migrated  to  the  Air 
Force's  Data  Systems  Modernization  (DSM)  program 
and  has  potential  application  to  future  systems 
such  as  the  Shuttle  Operations  and  Planning 
Complex  (SOPC). 
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Figure  1.  Evolution  of  the  STOL  Operations 
Language 


II.  OPERATIONS  LANGUAGE  IN  THE  MILITARY  SPACE 
ENVIRONMENT 

The  trend  in  military  space  ground  systems  is  in 
the  direction  of  increased  data  processing 
sophistication.  This  sophistication  is 
evidenced  by  larger  amounts  of  software  (as 
measured  by  source  lines  of  code)  and 
increasingly  distributed  processors  in  the 
ground  systems.  These  data  processing  resources 
(software  and  hardware)  bring  with  them  more 
demanding  requirements  for  performance 
monitoring  and  system  configuration  control. 
Likewise,  the  space  vehicles  and  payloads  which 
are  supported  by  these  ground  systems  demand 
control  and  monitoring  of  an  increasing  number  of 
complex  subsystems  and  on-board  computers.  Due 
to  the  costs  of  these  space  vehicles,  the 
tolerance  for  critical  errors  and  timely 
responses  to  contingencies  is  still  a  key  factor 
in  the  operation  of  any  ground  system. 

The  operational  exigencies  of  these  systems  have 
not  abated,  however  there  has  been  constant 
pressure  during  system  acquistions  to  reduce  the 
attendant  life  cycle  costs  of  these  systems.  A 
major  life  cycle  cost  element,  and  one  of  the 
most  visible,  is  the  composition  of  the  opera¬ 
tions  and  maintenance  personnel  organization 
required  for  a  ground  system.  Specifically,  much 
attention  has  been  focused  on  the  number  of 
personnel  required  to  operate  a  space  ground 
system  and  their  necessary  skill  and  training 
levels.  The  trade-offs  involved  in  minimizing 
these  parameters  often  justify  additional 
acquisition  funds  to  be  used  to  implement  auto¬ 
mated  techniques  which  can  further  reduce 
manpower-related  life  cycle  costs.  These 
techniques  focus  on  aiding  the  man-in-the-loop 
decision  making  processes  and  the  display  and 
control  man/machine  Interface. 


Man's  role  in  space  ground  systems  is  evolving  to 
one  of  being  a  resource  to  close  unplanned  open 
loops  in  the  system  operations,  as  illustrated  in 
figure  2.  Typically,  software  is  developed  to 
accept  functional  inputs,  process  them,  and  auto¬ 
nomously  provide  functional  outputs.  These 
inputs  and  outputs  can  relate  to  payload  data, 
spacecraft  telemetry  and  commands,  or  ground 
system  status  and  controls.  Further,  automated 
scheduling  functions  are  being  developed  to 
asynchronously  start  and  stop  such  operations. 
Due  to  the  inability  or  infeasibility  to  program 
all  possible  contingency  situations  and  the  risk 
associated  with  letting  such  automated  activi¬ 
ties  be  performed  unattended,  man  continues  to 
have  a  significant  role  in  space  ground  systems. 
This  role  however,  tends  to  be  a  monitor  of  the 
status  of  the  execution  of  the  system  and 
requires  him  to  be  the  primary  decision  maker 
when  conditions  are  non-  nominal.  This  generally 
occurs  when  portions  of  the  monitored  system 
status  do  not  appear  to  be  consistent  with  each 
other  or  when  the  system  has  been  programmed  to 
signify  an  alarm  state. 


Situations  such  as  these  initiate  a  stimulus- 
response  sequence  whereby  the  system  controller 
must  analyze  the  displayed  information  to  assess 
alternatives  and  reach  some  decision.  Most 
decisions  require  the  performance  of  some 
sequence  of  control  or  command  activities  to 
affect  the  desired  results.  These  man-in-the- 
loop  situations  may  either  be  nominal  cases  where 
it  has  been  determined  that  man's  positive 
control  over  a  situation  is  desired  or  non- 
nominal  cases.  These  non-nominal  situations  can 
range  from  the  fairly  routine,  for  example  where 
a  ground  system  equipment  reconfiguration  is 
needed;  to  a  time-critical  spacecraft  emergency. 
These  situations,  especially  the  later,  are 
characterized  by  the  need  for  quick  responses, 
often  requiring  lengthy  response  sequences,  and 
affording  little  tolerance  for  errors.  To 
compound  this  problem,  exercising  and  training  of 
non-nominal  situation  responses  is  generally 
limited. 
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To  summarize  the  problem  of  controller  responses 
in  a  military  space  ground  system;  the  demand  for 
speed  and  accuracy  of  command  and  control 
response  sequences  often  demands  utilizing  the 
skills  of  the  available  controllers  (which  system 
acquisition  pressures  force  us  to  reduce)  to 
exercise  control  over  data  processing  and  space¬ 
craft  systems  which  are  becoming  increasingly 
complex. 

System  control  Implementation  presents  signifi¬ 
cant  trade-offs  to  the  designer.  Controls  can  be 
simplified  by  increasing  the  amount  of  software 
Involved  on  the  computer  side  of  the  man/machine 
Interface.  For  example,  a  complex  sequence  of 
activities  could  be  coded  into  a  software  routine 
which  is  executed  via  a  simple  input  sequence. 
The  problem  with  this  approach  is  that  hard-coded 
responses  tend  to  become  Inflexible  and  difficult 
to  modify.  System  flexibility  has  become  key 
criterion  of  system  “goodness"  since  it  is  well 
recognized  that  over  a  system  life  cycle,  equip¬ 
ment,  communications,  and  software  will  (and 
should)  evolve.  A  flexible  system  therefore  is 
desired  to  be  able  to  adapt  to  changing  require¬ 
ments.  Flexibility  decries  hard-coded  routines 
because  of  the  attendant  configuration 
management  requirements,  test  considerations  and 
the  human  resources  required  for  implementing 
changes. 

An  alternative  to  high  level  hard-coded  controls 
is  manually  initiated  discrete  response 
sequences  (still  via  software)  but  at  a  very  low 
level.  These  sequences  provide  flexibility  in 
that  options  are  easily  selected  and  system 
adaptations  are  easily  accommodated.  The  problem 
which  results  is  that  the  required  response 
sequences  tend  to  become  long  -  since  they 
consist  of,  by  definition,  many  simple  discrete 
actions.  Previous  space  ground  systems  have 
addressed  the  problems  that  this  response 
approach  brings  to  bear  by  the  use  of  written 
procedures  or  checklists  to  guide  the  controller 
through  the  proper  sequence  of  steps  to 
accomplish  an  action.  Although  paper  procedures 
are  easier  and  less  costly  to  manage  and  change 
than  coded  software,  problems  are  still  Involved. 
These  problems  Include  the  ability  to  quickly 
locate  and  use  the  desired  procedure  and  the  fact 
that  manual  transcription  or  data  entry  errors 
are  common. 

The  operations  language  has  emerged  as  a 
technique  to  bridge  these  extremes  and  yet  has 
lost  little  in  the  compromise. 

III.  OPERATIONS  LANGUAGE  DIRECTIVES 

The  most  basic  element  of  an  operations  language 
is  the  operations  language  directive.  A  direc¬ 
tive  is  the  lowest  level  of  control  that  can  be 
exercised  in  a  system.  This  level  of  control 
Includes  both  control  of  software  processes  (such 
as,  start  telemetry  limit  checking,  or  present  a 
specified  display  on  a  particular  CRT)  and  the 
software  control  of  hardware  (turn  on  a  remote 


tracking  station's  high  power  amplifier, 
resynchronize  a  crypto  device,  initialize  a  CPU, 
etc.).  This  level  of  control  can  be  visualized 
by  imagining  a  totally  quiescent  system  and  then 
identifying  each  lowest  level  discrete  action 
over  which  system  operations  personnel  need 
control . 

The  syntax  of  a  directive  in  its  most  basic  form 
is: 

verb  parameters 

A  directive  consists  of  a  verb  and  an  optional 
set  of  parameters.  Basic  capabilities  of  an 
operations  language  include  the  use  of  a  standard 
character  set  as  well  as  the  use  of  constants  as 
parameters  (including,  as  appropriate,  decimal, 
binary,  octal,  hexidecimal,  real  numbers,  and 
strings).  The  list  below  illustrates  the  use  of 
various  forms  of  parameters  which  each  accomplish 
the  same  function  in  a  system. 

DIRECTIVE  PARAMETER  PARAMETER  TYPE 

CHE  o' 0000557  Octal 

CMD  704  REAL 

CMD  XMTR10FF  ALPHANUMERIC 

(MNENOMIC) 

This  example  uses  a  directive  (CMD)  to  transmit  a 
command  to  a  spacecraft.  In  the  first  form,  the 
actual  command  uplink  data  the  (bit  stream)  is 
given  by  an  octal  representation.  The  second 
implementation  of  this  directive  uses  a  real 
number,  where  704  is  an  assigned  command  number 
to  represent  the  command  data.  The  third  form 
uses  a  mnemonic  string  (transmitter  #1  off)  to 
represent  the  command  in  the  system’s  data  base. 

Other  uses  of  parameters  include  telemetry 
mnenomics  and  telemetry  frame  address  specifica¬ 
tion,  such  as: 

a)  LIMITS  OFF, BAT1 VOLT 

b)  CHART  TLM( 4,12) 

where  a)  is  a  directive  to  turn  off  limit 
checking  for  the  battery  #1  voltage  measurement 
and  b)  Is  a  directive  to  begin  strip  charting  the 
value  of  telemetry  main  frame  word  4,  subcommu¬ 
tated  word  12. 

The  original  STOL  concept  defined  a  basic  set  of 
directives  in  three  areas:  command,  telemetry, 
and  input/output.  These  areas  have  been 
Increased  in  recent  Implementations  and  now  also 
include  extensive  ground  system  control. 

IV.  PROCEDURES 

The  major  benefit  of  an  operations  language  is 
provided  by  the  capability  of  developing  opera¬ 
tions  language  procedures.  The  concept  of  opera¬ 
tions  language  procedures  centers  on  the  ability 
to  prepare  off-line,  sequences  of  directives 
which  are  grouped  together  and  given  a  single 
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procedure  name.  Procedures  are  filed  in  the 
system  on  an  immediate  access  storage  medium 
where  they  can  be  retreived  and  executed  via  a 
single  reference.  This  single  reference  is 
actually  a  directive,  the  START  directive,  with 
the  name  of  the  procedure  as  the  argument. 
Procedures  are  valuable  because  they  provide 
repeatible  orders  of  fixed  sequences.  These 
procedures  are  able  to  be  prepared  off-line  and 
fully  tested  and  validated  prior  to  their  release 
for  operational  -se.  In  routine  operations, 
procedures  are  valuable  since  they  can  relieve 
system  controllers  from  repetitive  tasks  - 
thereby  reducing  the  possibility  of  operator 
errors . 

There  are  several  key  features  of  an  operations 
language/procedure  implementation.  Run-time 
visibility  is  important  since  a  procedure  is 
merely  a  technique  for  providing  a  short  cut  for 
fully  manual  control.  The  man-in-the-loop  should 
always  have  visibility  into  the  sequence  of 
directives  being  executed.  This  is  accomplished 
by  an  interpretive  execution  of  each  directive  in 
the  procedure.  Manual  controls  must  always  be 
able  to  be  exercised  over  the  procedure 
execution.  This  Includes  the  pre-emptive  direc¬ 
tive  HALT  which  stops  procedure  execution 
immediately.  Also,  built-in  controls  can  be 
provided  by  the  procedure  writers  by  the 
inclusion  of  procedure  control  directives  such  as 
HOLD  (an  indefinite  wait  until  the  controller 
enters  the  GO  directive),  or  WAIT  n  (where  n  is 
some  number  of  seconds).  The  ability  for  a 
controller  to  put  the  procedure  execution  into  a 
single  step  mode  (via  the  STEP  directive)  is  also 
a  key  element  of  an  operations  language  imple¬ 
mentation. 

It  should  be  stressed  that  procedures  are  not 
intended  to  be  substitutions  for  software. 
Allocations  are  made  in  every  system  design  in 
terms  of  what  is  to  be  fully  automated  and  what 
is  to  be  made  more  discrete  in  terms  of  the 
desired  level  of  control.  Procedures  are 
powerful  because  they  provide  the  flexibility  to 
permit  more  automation  and  standardization,  but 
still  with  execution  visibility  and  manual 
controls  and  overrides  available.  Procedures  are 
provided  with  additional  power  when  extended  by 
the  concepts  of  argument  substitution,  nesting 
and  arithmetic  and  logical  condition  testing  and 
branching.  The  basic  directive  format  presented 
earlier  when  extended  for  use  in  a  procedure, 
results  in  the  modified  format: 

label  verb  parameters  icomnent 

where  the  label  field  has  been  added  for 
branching  and  the  comment  field  has  been  added 
for  self-documentation.  A  sample  procedure  is 
presented  in  figure  3.  This  entire  procedure 
could  be  executed  under  the  watchful  eye  of  a 
system  controller  merely  by  the  entry  of  the 
directive: 


RROC  9W.RR0C 

•  THIS  IS  A  SANRLE  PROCEDURE 

•  IT  PRESENTS  A  DISPLAY  Of  A  SPACE  VEHICLE'S  (SVj)  STATUS 

;  OR  THE  CONTROLLER 1 S  CRT;  HA  ITS  FOR  HIS  INPUT  To 

;  CONTINUE;  TURNS  ON  A  GROUND  STATION'S  HIGH  POWER 

AMPLIFIER  (HP*)  FOR  COMUNOINC;  CHECKS  CONSTRAINTS  TO 
VERIFT  THAT  TELEHETRT  INOICATES  THAT  THE  SV's 
;  REACTION  WHEa  (RW)  IS  CURRENTLV  OFF;  TRANSMITS 
;  THE  CORRUNO  TO  TURN  THE  RH  ON;  WAITS  FOR 

COMINO/TELENETRV  PROPAGATION  ANO  PROCESSING  OELATS; 

;  PERFORMS  A  FUNCTIONAL  VERIFICATION  OF  THE  COWUNO  VIA  A 
;  TaEHETRV  CHECK;  ANO  TURNS  OFF  THE  HPA 


DISPLAY 

HOLD 

SVSTATUS 

CONFIGURE 

HPA-ON 

VERIFY 

RM1STAT-0FF 

am 

RW10N 

WAIT 

10 

VERIFY 

RM1STAT-0R 

CONFIGURE 

ENOPROC 

HPA-OFF 

DISPLAY  SV  STATUS  ON  CRT 
HOLD  FOR  OPERATOR  RELEASE 
TURN  GROUND  STATION  HPA  ON 
CONFIRM  RW  IS  NOW  OFF 
SEW  COMtAW  TO  TURN  RW  ON 
WAIT  10  SECONOS  FOR  CMO/TLM 
OELATS 

CONFIRM  RW  IS  NOW  ON 
TURN  OFF  THE  HPA 
EW  OF  PROCEOURE 


Figure  Sample  Procedure 


One  operations  language  Implementation  principle 
developed  with  STOL  is  the  principle  of  run-time 
traceability.  Similar  to  run-time  visibility, 
this  principle  dictates  that  every  directive 
executed  within  a  procedure  should  be  able  to  be 
traced  and  identified,  if  necessary,  due  to 
system  anomally  investigations,  etc.  This 
dictates  the  requirements  for  a  system  log  or 
equivalent  to  record  each  directive  that  was 
executed.  Typically,  this  log  is  time-tagged. 

V.  APPLICATIONS  OF  OPERATIONS  LANGUAGE  PROCEDURES 

Operations  language  procedures  have  application 
in  many  areas  in  a  space  ground  system.  Space 
vehicle  contacts  can  be  structured  utilizing 
procedures  extensively.  These  contacts  can 
include  routine  housekeeping/state-of-health 
contacts,  as  well  as  regular,  but  less  frequent 
types  of  contacts  such  as  battery  reconditioning, 
or  orbit/attitude  maneuvers.  Non-nominal 
situations  can  often  be  dealt  with  by  the  use  of 
preplanned  contingency  procedures.  With 
adequate  space  vehicle  simulation  capabilities, 
many  contingency  procedures  can  be  developed, 
tested  and  kept  on  file  until  (if)  they  are 
needed.  Figure  4  illustrates  a  sequence  of 
contingency  activities  for  a  space  vehicle  which 
could  be  implemented  in  operations  language 
procedures. 

Since  the  hardware,  software  and  communications 
components  of  modern  ground  systems  have  grown 
more  complex  and  more  widely  distributed,  the 
number  of  actions  and  degree  of  knowledge 
required  to  reconfigure  these  systems  has  also 
increased.  Activities  required  to  reconfigure 
system  components  can  be  greatly  simplified  by 
the  use  of  operations  language  procedures. 
Activities  easily  accomodated  by  procedures 
include,  hardware  reconfiguration,  software/mode 
control,  readiness  testing  and  remote  diagnostic 
execution.  Again,  both  normal  and  contingency 
operations  are  accommodated  easily  by  the  use  of 
procedures. 


START  SMPLPROC 


ACTION 


PREDEFINED  PROCEDURES 


Figure  4.  Space  Vehicle  Contingency  Procedures 


Procedures  can  also  be  used  as  the  basic  units  of 
scheduling  since  modern  systems  often  have 
requirements  for  schedule  driven  operations.  As 
illustrated  in  figure  5,  procedures  can  serve  as 
building  blocks  to  produce  arbitrarily  complex 
scheduled  activities  for  both  space  vehicle  and 
ground  system  support. 


Figure  5.  Scheduling  Via  Procedure  Building 
Blocks 


VI.  EXTENSIONS  TO  THE  OPERATIONS  LANGUAGE  CONCEPT 

The  operations  language  concept  can  be  extended 
with  benefit  into  the  system  design  arena.  When 
the  set  of  system  directives  is  developed  early 
enough  in  the  design  phase,  it  provides  a 
convenient  road  map  to  trace  system  end-to-end 
operation.  This  is  illustrated  in  figure  6. 
Frequently,  system  engineering  decomposes  the 
development  of  a  system  into  hardware  and 
software  components  and  inter-component  inter¬ 
face  are  defined  prior  to  the  solidification  of 
the  operational  uses.  What  can  result  is  a 
series  of  inter-component  transmutations  of 
control  data,  which  can  increase  the  complexity 
and  size  of  a  system.  If,  however,  the  set  of 
directives  is  developed  and  controlled  early  in 
the  systems  engineering  process,  optimized 
system  interfaces  and  protocol  can  be  developed. 
This  can  reduce  system  software,  interfaces,  and 
provide  for  a  more  easily  understood  system  from 
an  end-to-end  viewpoint. 

The  ability  to  easily  trace  the  flow  of  control 
through  the  system  facilitates  the  system 
testing  processing  since  the  effect  of  each 
directive  can  be  traced  and  analyzed  in  an 
orderly  fashion  as  system  integration  proceeds. 
At  a  lower  level,  unit  and  string  testing  can  be 
performed  with  a  high  degree  of  similarity  to 
actual  operational  conditions. 

Significantly,  the  entire  test  program  can  be 
built  by  using  operational  language  procedures. 
These  procedures  are  efficient  time  savers  since 
by  providing  repeatable  sequences,  regression 
testing  is  easily  performed.  The  building  of 
test  scenarios  is  easily  accomplished  via  opera¬ 
tions  language  procedures. 

VII.  MILITARY  USER  CONSIDERATIONS 

An  analysis  of  the  profile  of  the  users  of  modern 
military  space  ground  systems  highlights  a  trend 
toward  the  planned  use  of  Air  Force  ("blue  suit") 
personnel  for  operations.  This  trend,  however, 
brings  with  it  several  considerations  which  make 
operations  language  techniques  even  more 
important.  The  Air  Force  has  a  built-in  turnover 
rate  of  approximately  33  percent,  due  to  a  basic 
CONUS  three  year  tour  of  duty.  This  turnover 
level  is  higher  and  the  required  training 
activity  level  is  higher  than  in  a  steadier  state 
environment  such  as  a  civil  service  or  a 
contractor  staffed  ground  system. 

The  application  of  an  operations  language  and 
especially  of  operations  language  procedures 
provides  a  significant  benefit  to  military  space 
ground  systems.  Its  use  permits  an  off-loading 
of  skill  levels  by  permitting  the  operations 
planners  (sometimes  called  "back  room" 
personnel)  to  develop,  test  and  validate  (via 
simulation)  procedures.  The  system  controllers 
then  do  not  require  as  much  detailed  training 
into  the  Internals  of  procedures  in  order  to  use 
and  execute  them.  In  this  fashion  the  skill, 
training  and  even  number  of  operations  personnel 


can  be  reduced  -  all  contributing  to  a  reduced 
life  cycle  cost.  Flexibility  of  the  system  is 
increased,  since  modification  of  procedures  is 
easier  and  less  costly  than  software  modifica¬ 
tions.  This  also  reduces  life-cycle  costs. 


System  effectiveness  is  increased  since  in 
practice,  operations  language  techniques  are 
being  coupled  with  more  effective  man/machine 
Interface  techniques  such  as  pointing,  menus, 
prompts,  graphic  displays,  help  techniques,  etc. 
These  all  compound  system  effectiveness.  System 
designers  are  further  provided  with  tools  to 
counteract  unskilled  typists  as  users,  as  well  as 
the  ability  to  balance  the  significant  overload/ 
boredom  issue.  Procedures  also  provide  excellent 
tools  for  handling  emergencies,  a  factor  that  is 
also  important  in  reducing  errors. 

VIII.  SUMMARY 


The  concept  of  an  operations  language  has 
involved  over  the  years  on  several  space 
programs,  but  has  only  recently  received  a  forma¬ 
lization  with  its  introduction  into  the  military 
space  ground  system  environment.  The  concept 
involves  defining  and  managing  the  1  «$t  level 
of  system  control,  deemed  the  directives. 
Directives  are  able  to  be  grouped  into  stored 
fixed  repeatable  sequences  which  are.  called 
procedures.  These  procedures  are  able  to  be  used 
for  both  normal  and  contingency  operational 
activities.  Procedures  are  able  to  be  developed 
and  tested  by  skilled  "back  room"  specialists  and 
their  use  can  reduce  operator  errors.  Due  to  the 
need  for  reduced  skill  and  training  levels  in  the 
modern  military  space  ground  system,  the  opera¬ 
tions  language  concept  can  be  a  valuable  tool  for 
system  designers  and  provide  a  reduction  In 
system  life  cycle  costs. 
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ABSTRACT 

Present  U.S.  military  capability 
relies  heavily  on  Earth  satellites  to 
maintain  connectivity.  The  essential 
nature  of  these  satellite  systems  has  made 
them  tempting  targets  to  nuclear  attack  in 
wartime.  The  author  reviews  U.S.  history 
in  high-altitude  nuclear  device  testing 
and  nuclear  effects  testing  on  satellites, 
events  in  which  he  directly  participated. 
Physics  of  the  production  of  nuclear  en¬ 
hanced  high-altitude  electron  belts  are 
reviewed.  The  author  discusses  primary 
effects  of  the  enhanced  environment  on 
satellite  components.  A  glimpse  into 
future  satellite  hardening  reveals  mea¬ 
sures  against  developing  directed  energy 
weapons . 


HISTORICAL  PERSPECTIVE  OF 
SATELLITE  SYSTEM  SURVIVABILITY 

Three  nuclear  weapons  tests  are 
reviewed  which  involve  satellites  and  some 
implications  for  satellite  survivability. 
The  first  nuclear  tests  to  be  reviewed  are 
the  ARGUS  I,  II,  and  III  events  in  1958 
and  the  Explorer  IV  satellite  performance 
in  the  trapped  radiation  belts.  From  late 
1958  to  late  1961  there  were  no  atmo¬ 
spheric  nuclear  weapon  tests  and  during 
this  time  a  large  number  of  satellites 
were  orbited.  In  1962  the  STARFISH  event 
was  conducted  in  the  Pacific  and  affected 
a  number  of  satellites  in  orbit  at  that 
time.  The  final  test  to  be  discussed  was 
the  underground  nuclear  weapon  test — 

HURON  KING  in  1980  at  the  Nevada  Test  Site 
— on  which  a  special  hardened  satellite 
was  exposed. 

These  tests  cover  briefly  the  past 
and  present  factors  bearing  on  satellite 
survivability.  For  future  threats,  refer¬ 
ence  is  made  to  a  recent  study,  "High 
Frontier — A  New  National  Strategy",  and  in 
particular  to  "Chaper  II  Annex:  Surviva¬ 
bility  of  Space  Systems" 


L*wn  of  the  Space  Age 

For  our  purposes,  the  Space  Age  be¬ 
gins  with  SPUTNIK  on  4  October  1957.  In 
response  to  SPUTNIK,  the  United  States 
formulated  the  ARGUS  exoatmospheric 
nuclear  weapons  test  for  conduct  in  1958 
with  the  Explorer  IV  satellite  as  the 
prime  measurement  system. 

The  author  was  Technical  Director  of 
the  Defense  Atomic  Support  Agency  in  the 
DoD,  and  had  operational/contractual  re¬ 
sponsibility  for  the  conduct  of  ARGUS  and 
arrangements  for  Explorer  IV  from  NASA. 
The  newly  formed  Advanced  Research  Pro¬ 
jects  Agency  was  the  overall  executive 
agency  for  the  program. 


Exoatmospheric  Burst 

A  nuclear  explosion  outside  the 
Earth’s  sensible  atmosphere  but  still 
within  its  geomagnetic  field,  such  as  at 
several  hundred  miles  altitude,  results  in 
a  strong  interaction  between  the  magnetic 
field  and  the  expanding,  ionized  bomb 
fragments  (Figure  1).  The  kinetic  energy 
of  the  bomb  plasma  is  converted  into  work 
in  pushing  aside  the  magnetic  fiej.d  lines. 
Bomb  debris  moving  along  the  magnetic 
field  lines  is  unconstrained  and  plunges 
into  the  Earth’s  atmosphere  in  the  conju¬ 
gate  regions,  producing  intense  auroral 
displays.  Relativistic  electrons  result¬ 
ing  from  fission  product  decay  are  effec¬ 
tively  trapped  in  the  Earth's  geomagnetic 
field  and  rapidly  spread  from  west  to  east 
completely  around  the  Earth,  forming  an 
artificial  Van  Allen  belt  with  many  of  the 
same  features  as  the  natural  Van  Allen 
belts.  The  ALGUS  nuclear  explosions,  con¬ 
ducted  by  the  United  States  in  1958,  had 
been  designed  in  late  1957  to  produce  this 
trapped  electron  effect  even  before  the 
natural  Van  Allen  belts  were  discovered  in 
the  data  from  the  first  United  States 
satellite — Explorer  1. 


The  injected  and  trapped  electron 
environment  from  a  high-altitude  nuclear 
weapon  detonation  is  one  of  the  most 
severe  nuclear  environments  for  low- 
altitude  spacecraft.  Precautions  were 
taken  in  the  design  of  Explorer  IV  and  its 
instruments  to  perform  in  the  predicted 
artificially  produced  Van  Allen  belt.  So, 
from  the  very  beginning,  some  radiation 
hardening  has  been  incorporated  into  our 
satellite  designs. 


Last  of  the  Large  Yield  High-Altitude 
Nuclear  Weapons  Tests 

Satellite  vulnerability  to  nuclear 
weapon  radiation  was  most  dramatically 
demonstrated  with  the  9  July  1962  STAR¬ 
FISH  nuclear  weapon  test  which  caused 
failure  in  about  seven  satellites  from 
damage  that  was  produced  by  trapped 
electrons  injected  into  the  Earth's  mag¬ 
netic  field  by  the  detonation. 

The  author  was  Chief  DASA's  (DoD) 
technical  representative  for  planning  and 
conduct  operation  FISHBOWL  in  the  Pacific 
in  1962  in  which  STARFISH  was  one  of  five 
high-altitude  tests.  The  times  of  the 
high-altitude  test  detonations  were 
closely  coordinated  with  NASA  to  ensure 
that  no  important  satellites  were  in  line- 
of-sight  of  the  nuclear  bursts.  Hence, 
none  received  direct  nuclear  weapon  radia¬ 
tions  such  as  x-rays,  gamma  rays,  and  neu¬ 
trons  . 

For  a  megaton  event  (1.4MT)  like 
STARFISH  at  400  kilometers  altitude  above 
Johnston  Island,  approximately  10%  of  the 
fission  spectrum  electrons  are  trapped  in 
the  Earth's  magnetic  field  and  produce  a 
long-lived  radiation  belt.  The  principle 
damage  mechanism  was  electron  produced 
degradation  (premature)  and  failure  of  the 
solar  arrays  on  the  satellites  as  they 
passed  through  the  trapped  radiation 
belts.  Specifically,  the  satellites 
Transit  4B,  Traac,  and  Ariel  had  solar 
array  failures  within  about  a  month,  and 
the  event  caused  the  eventual  failure  of 
Starad,  Explorer  15,  Injun  I,  and  Telstar. 

Concern  for  the  vulnerability  of  U.S. 
satellites  lead  to  the  Joint  Chiefs  of 
Staff  issuing  in  1968  guidelines  to  be 
used  as  specifications  for  nuclear  harden¬ 
ing  of  military  satellites.  The  JCS 
guidelines  were  subseauently  revised  in 
June  1976 — and  are  classified  and  will  not 
be  discussed  here. 

The  U.S.  military  force  structure  has 
become  increasingly  dependent  on  satellite 
systems  for  navigation,  communication,  and 
svft’veillance .  Concern  has  mounted  regard¬ 
ing  U.S.S.R.  capability  and  capacity  to 


use  an  antisatellite  (ASAT)  system  against 
U.S.  spacecraft.  This  lead  to  the  Presi¬ 
dential  Directive  in  1978  that  orders  an 
increased  survivability  of  U.S.  space 
systems . 

In  addition  to  satellite  hardening  to 
trapped  electron  radiation,  hardening  to 
the  direct  nuclear  radiation  is  empha¬ 
sized.  Defense  Satellite  Communication 
System  II  (DSCS  II)  was  the  first  to  have 
nuclear  survivability  and  rad) j  .ion  hard¬ 
ening  included  as  a  contractual  require¬ 
ment. 

A  principle  threat  to  the  ground- 
based  terminals  of  satellite  systems  is 
the  EMP  produced  by  high-altitude  nuclear 
detonations.  EMP  simulations  (airborne 
and  ground-based)  can  effectively  test  and 
validate  the  hardness  of  the  ground-based 
terminals  of  satellite  systems. 


Underground  Nuclear  Weapons  Effects  Test¬ 
ing  of  Satellite  Systems 

Underground  nuclear  weapons  effects 
testing  provides  a  realistic  simulation 
environment  for  validating  satellite  hard¬ 
ness  to  direct  nuclear  weapon  radiation. 
Considerable  confidence  in  satellite 
hardening  technology  was  gained  from  the 
HURON  KING  UGT  in  1980.  The  test  object 
was  STARSAT  ( SGEMP  Test,  Analysis  and 
Research  Satellite)  based  on  the  design  of 
General  Electric ' s  defense  systems  com¬ 
munication  satellite  -  DSCS  3.  The  HURON 
KING  tests  show  that  radiation  hardening 
techniques  used  in  military  satellite 
designs  are  effective  and  that  the  models 
used  to  predict  response  to  nuclear  radia¬ 
tion  are  fairly  accurate. 


GHOSTS  OF  FUTURE  THREATS 

Future  space  systems  must  incorpo¬ 
rate  hardening  against  the  developing 
Directed  Energy  technology.  Some  of  the 
Directed  Energy  technologies  include 
(besides  the  conventional  weapons  systems 
of  kinetic  energy  pellets)  : 

-  High  energy  lasers  (HEL) 

-  Neutral  Particle  beams  (NPB) 

-  High  power  microwaves  (HPM) 

-  Electromagnetic  pulse  (EMP) 

r  jncepts  for  eventual  hardening  of 
spacecraft  systems  against  Directed  Energy 
threats  are  in  a  very  early  infant  stage. 

Space-based  Directed  Energy  weapons, 
if  they  are  ever  deployed,  will  still  need 
to  be  hardened  against  nuclear  interceptor 
attack  since  they  will  become  high-value 
targets . 
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ABSTRACT  What  is  reliability?  There  are  many 

definitions.  For  our  purpose,  I  will 
Space  systems  and  satellite  communi-  simply  say,  does  the  system  work  as 
cations  are  now  a  reality.  As  these  specified  for  the  required  time.  Relia- 

systems  become  more  important  to  our  bility  is  not  a  simple  factor.  It 

military  missions,  we  must  ensure  we  have  depends  on  early  planning,  effective 
reliable  equipment.  The  role  of  reliabi-  design,  adequate  system  and  component 

lity  is  not  just  the  responsibility  of  testing,  and  for  many  space  systems, 

the  project  reliability  engineer.  The  redundant  capability  in  critical  areas, 

program  manager  and  the  user  must  under-  Reliability  as  an  engineering  discipline 

stand  the  importance  of  the  reliability  can  be  very  detailed  and  abstract  for 

program.  The  designers  and  users  must  someone  who  has  not  studied  the  mathe- 

have  a  mutual  understanding  of  the  matical  equations  and  simulation  models, 

program  goals.  If  the  engineer  is  the  I  am  not  suggesting  that  every  space 

only  one  who  can  understand  the  system,  program  user  or  program  manager  should  be 

the  user  will  not  agree  it  is  what  is  a  reliability  engineer.  However,  a  basic 

needed  and  the  program  manager  will  not  awareness  of  the  discipline  would  be 

support  the  funding  requirement.^—  helpful. 


RELIABILITY  AWARENESS 

Reliability  is  an  obvious  requirement 
in  space  programs.  Even  as  we  enter  the 
shuttle  era,  we  still  have  not  fully 
developed  an  on-orbit  repair  capability 
for  our  COMSATS.  Reliability  is  not  a 
factor  which  can  be  taken  for  granted  by 
either  the  program  manager  or  the  user. 

A  program  manager  must  be  aware  of 
reliability's  priority  in  planning, 
potential  for  funding  requirements  and 
the  necessity  for  extensive  testing.  The 
reliability  program  can  be  expensive  and 
is  an  area  where  some  try  to  cut  costs. 
What  may  be  a  savings  for  the  program 
manager,  however,  may  be  very  expensive 
to  the  user.  "The  costs  of  even  a  modest 
interruption  of  service  can  far  exceed 
the  expense  saved  by  buying  the  cheapest 
thing  available.  Quality  and  reliability 
will  increasingly  be  dominating  criteria 
for  business  as  they  have  long  been  for 
the  military. " (1)  This  article  will 
address  the  need  for  reliability  aware¬ 
ness  for  both  the  program  manager  and 
the  user. 


Program  Manager's  point  of  View 

The  program  manager  is  given  a 
multitude  of  guidance  and  program  direc¬ 
tives  to  follow.  DOD  Directive  5000.1 
and  DOD  Instruction  5000.2  outline  proce¬ 
dures  and  responsibilities  for  system 
acquisition.  "The  program  manager  shall 
be  responsible  for  acquisition  and 
fielding  (in  accordance  with  instructions 
from  line  authority)  a  system  that  meets 
the  approved  mission  need  and  achieves 
the  established  cost,  schedule,  readiness 
and  affordability  objectives. " (2)  The 
areas  of  readiness  and  affordability  are 
the  key  areas  relating  to  reliability.  I 
will  address  these  both  through  reliabil¬ 
ity  planning.  My  main  concern  is  the 
priority  of  reliability  in  the  design 
and  planning  phase.  Some  may  say  that 
we've  been  building  satellites  and  other 
space  programs  with  measured  increases  in 
success  since  the  1960s.  The  lessons 
learned  certainly  ensure  reliability  of 
our  new  systems.  You  might  say  we  have 
built  enough  ground  radios  that  this 
should  also  be  true  for  new  radios. 

Well,  it  isn't.  During  a  previous 
assignment,  I  worked  on  a  major  program 
that  didn't  get  serious  enough  about 
reliability  until  we  were  planning 
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production.  We  had  not  ensured  perfor¬ 
mance  for  the  user  until  we  were  drafting 
the  production  contract  request  for 
proposal.  There  were  always  hotter  fires 
which  required  the  dollars.  Reliability 
didn't  have  a  high  priority.  A  program 
manager  must  consider  reliability  of  a 
space  system  at  the  same  level  of 
priority  in  planning  as  cost,  schedule 
and  as  a  key  element  of  mission 
performance.  We  must  look  to  previous 
programs,  other  services  and  NASA  for 
help.  "NASA'S  philosophy  is  that 
reliability  is  designed  in  and  defects 
are  tested  out  .  .  .  there  is  a 
disciplined  and  coordinated  attack 
against  unreliability  on  three  fronts: 

1.  Application  of  effective  design  prin¬ 
ciples  -  and  the  extensive  and  meticulous 
review  of  designs. 

2.  Control  and  screening  of  all  parts. 

3.  Testing  of  the  entire  spacecraft  or 
its  prototype  for  predicted  capabili¬ 
ties."  (3) 

In  addition  to  a  reliable  design  with 
numerous  detailed  reviews,  the  program 
manager  must  ensure  adequate  planning  for 
testing  and  budgeting.  "In  its  threefold 
attack  on  unreliability,  NASA  has  found 
design  to  be  the  most  critical  deter¬ 
minant  of  spacecraft  performance. " (3) 

While  design  is  critical  for  the  program 
manager,  the  reliability  problem  is  not 
solved  with  just  the  design.  The  affor¬ 
dability  factor  now  must  be  addressed. 
Many  think  it  is  going  to  be  years  before 
we  actually  build  the  system,  so  we'll 
just  increase  the  budget  next  year.  That 
is  not  realistic  or  feasible  considering 
the  acquisition  funding  requirements. 

The  designers  and  program  manager  must 
consider  the  cost  of  high  reliability 
components,  the  amount  of  testing  and  the 
cost  of  special  test  chambers  to  simulate 
space  conditions.  The  voyager  spacecraft 
had  undergone  2000  hours  of  testing 
before  it  was  launched (4).  You  must 
determine  whether  any  new  testing  or 
screening  techniques  must  be  developed 
and  what  this  research  will  cost.  W.  J. 
Willoughby,  Jr.,  as  Deputy  Chief  of  Naval 
Material,  Reliability  Maintainability  and 
Quality  Assurance,  has  devoted  a  great 
deal  of  time  developing  the  techniques 
and  requirements  for  the  Navy  to  decrease 
corporate  costs  and  increase  fleet 
readiness.  The  Appendix  to  NAVMAT 
P-9492,  Navy  Manufacturing  Screening 
program,  describes  a  method  of  random 
vibration  testing  for  electronic  compo¬ 
nents  to  reduce  cost  because  test  faci¬ 
lity  cost  has  become  a  major  obstacle(5). 
The  consideration  of  special  radiation 
tests  and  other  space  environmental  fac¬ 
tors  are  of  importance  in  determining  the 
funding  requirements  for  space  system 
acquisition.  They  are  all  expensive. 


What  reliability  measures  can  you 
afford?  "When  reliability  is  defined 
quantitatively,  it  is  specified,  ana¬ 
lyzed  and  measured  and  becomes  a  para¬ 
meter  of  design  that  can  be  traded  off 
against  other  parameters  such  as  cost 
and  performance (6) .  The  program  manager 
must  be  aware  of  all  these  factors  and 
how  they  interact  with  other  areas. 
Reliability  and  these  related  facets  can 
be  a  major  portion  of  the  system  life 
cycle  funding  requirement. 

The  program  manager  must  include 
reliability  as  a  high  priority  starting 
in  Concept  Exploration  to  carry  it 
through  the  life  of  a  new  program.  The 
affordability  issue  must  be  looked  at 
from  the  system  life  cycle  point  of 
view,  not  from  one  cycle  in  the  acquisi¬ 
tion  process.  The  life  cycle  costs  of  a 
space  system  are  not  the  traditional 
acquisition  costs  plus  maintenance  and 
disposal.  The  opportunity  cost  must  be 
considered.  What  is  the  cost  to  your 
mission  if  the  system  fails?  Can  you 
plan  for  replenishment  launches  to  con¬ 
tinue  service?  How  would  a  replenish¬ 
ment  launch  effect  other  programs? 

Where  is  your  program  in  priority  for  a 
second  launch  vehicle?  And  what  would 
it  cost  if  you  had  to  redirect  the 
contractor's  efforts  for  a  replacement 
system? 

What  Can  The  User  Do7 

you've  identified  your  requirement, 
now  where  is  your  new  system?  The  user 
needs  an  awareness  of  reliability  for  a 
number  of  reasons.  First  of  all,  are 
your  availability  requirements 
realistic?  With  a  new  system,  we  always 
indicate  the  optimal  requirement  for 
fear  that  they  will  be  cut  later.  If 
99.9%  availability  is  necessary, 
recognize  that  this  will  have  an  impact 
on  many  other  factors.  Be  aware  that  as 
users  we  normally  write  requirements 
from  a  system  capability  viewpoint 
(i.e.,  number  of  channels,  system 
availability,  etc.),  not  from  a  design 
interrelationship  viewpoint  (i.e., 
redundancy  vs.  weight).  The  end  product 
is  a  combination  of  many  factors.  As  we 
all  realize,  we  do  not  have  forward 
supply  points  in  space.  To  achieve  your 
mission  goals,  the  design  may  require 
extensive  redundancy.  Redundancy  will 
affect  weight,  which  could  limit  your 
requirement  for  a  specific  number  of 
channels.  The  particular  launch  vehicle 
weight  limit  must  be  added  to  this 
assessment.  Another  factor  to  consider 
is  your  initial  operational  capability 
(IOC)  requirement.  Will  your  IOC  sup¬ 
port  the  time  required  for  the  extensive 
testing  necessary  to  ensure  reliability? 
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As  a  user,  become  involved  early. 

Have  the  right  people  attend  early  design 
reviews.  Designate  someone  to  be  a  member 
of  the  reliability  group.  Don't  make 
this  the  person's  third  or  fourth  addi¬ 
tional  duty.  The  user  must  also  give 
reliability  the  priority  it  deserves. 
Select  someone  who  will  provide  con¬ 
tinuity  to  the  program  as  it  develops. 

Be  flexible  and  realistic.  Recognize  the 
problem  areas  and  be  willing  to  work  out 
tradeoffs  with  the  program  manager. 

There  is  no  one  answer  for  every  program. 
As  a  user  of  a  space  program,  communica¬ 
tions  or  otherwise,  your  mission  is 
depending  on  reliability. 

Many  program  managers  prefer  to  keep 
the  user  as  far  away  from  program  office 
business  as  possible,  until  turnover.  I 
feel  if  you  are  informed  and  aware  of  the 
importance  of  reliability  planning,  you 
can  be  a  valuable  asset  to  a  program 
manager.  Reliability  is  only  one  area 
where  we  need  a  unified  voice  from  the 
program  manager  and  the  user  to  present 
the  program  to  Air  Staff.  If  the  develo¬ 
pers  clearly  understand  and  can  provide 
what  the  user  wants,  and  the  user 
understands  and  can  support  the  design 
logic,  the  program  is  on  its  way  to 
success,  a  cooperative  approach  can 
alleviate  side  battles  within  the  program 
family,  allowing  more  energy  to  present  a 
unified  program  through  the  approval 
channels. 

Conclusions 


(4)  W.  Richard  Scott,  "Voyager:  By 
launch  time,  the  spacecraft  had 
undergone  over  2000  hours  of  testing," 
IEEE  spectrum.  Reliability,  (18:68-70): 
October,  1981. 

(5)  W.  J.  Willoughby,  Jr.,  NAVMAT 
P-9492,  Navy  Manufacturing  Screening 
Program,  May  1979. 

(6)  B.  S.  Dhillon  and  Chanan  Singh, 
Engineering  Reliability,  New  York:  John 
Wiley  k  Sons,  1981,  p.  1. 


Reliability  cannot  be  assumed  as  just 
another  operational  requirement.  The 
program  manager  and  the  user  must  be 
aware  of  the  importance  and  priority  in 
planning.  Even  with  the  proper  planning, 
the  degree  of  reliability  required  in  our 
space  programs  could  make  reliability  the 
most  costly  part  of  the  program.  If  it 
is  not  given  a  high  priority  early  and 
planned  for  in  each  future  phase  of  the 
program,  it  could  be  our  biggest 
stumbling  block.  We  must  all  be  aware  of 
the  implications  of  reliability  and  plan 
early. 
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ABSTRACT 

V 

This  paper  traces  the  evolution  of  Air  Force 
space  mission  command,  control,  and  communications 
as  the  Air  Force  Satellite  Control  Facility  has 
matured  and  as  the  Space  Shuttle  becomes  operation¬ 
al.  The  internetting  of  Air  Force  and  NASA  support 
networks  is  described,  as  exemplified  by  the  devel¬ 
opment  of  the  Consolidated  Space  Operations  Center. 
Recent  trends  toward  an  evolutionary  methodology 
for  acquiring  space  command  and  control  systems  are 
also  discussed. 


INTRODUCTION 


Acquisition  and  implementation  of  new  capa¬ 
bilities  for  Air  Force  space  command,  control,  and 
communications  are  typically  thought  of  as  a  series 
of  "new  starts"  that  provide  unique,  program- 
specific  capabilities.  In  actual  fact,  for  the 
past  twenty  years  USAF  satellite  tracking,  telem¬ 
etry,  and  command  (TT&C )  development  has  been  much 
more  of  an  evolutionary  process,  with  new  capabil¬ 
ities  being  added  to  the  satell ite  support  network 
to  meet  the  common  needs  of  a  number  of  users. 


Manned  spaceflight  support  has  tended,  at 
least  through  the  Apollo  mission  series,  to  follow 
the  "typical"  new-start  development  methodology. 
However,  the  advent  of  the  Space  Transportation 
System  (STS)  as  the  first  truly  operational  US 
manned  spaceflight  program  has  led  enhancements  to 
the  STS  ground  support  network  to  follow  a  much 
more  evolutionary  path. 

Another  significant  phase  in  the  evolution  of 
these  support  networks  has  resulted  from  recent 
emphasis  of  national  space  policy  on  network  sur¬ 
vivability,  support  flexibility,  and  maximum  opera¬ 
tional  efficiency.  This  phase  is  the  internetting 
of  common-user  Air  Force  facilities,  previously- 
dedicated  Air  Force  facilities,  and  NASA  facilities 
into  an  integrated  Space  Control  Network,  perhaps 
best  exemplified  by  the  development  of  the  Consol¬ 
idated  Space  Operations  Center  (CSOC). 

This  evolutionary  approach  to  new  capabilities 
has  now  been  extended  to  the  acquisition  methodol¬ 
ogy  used  in  systems  development.  First,  competi¬ 
tive  definition  or  design  contracts  are  used  in  the 
selection  of  a  development  contractor.  Next,  after 


contractor  selection,  development  contracts  feature 
an  incremental,  or  block,  approach,  which  provides 
flexibility  of  implementation  within  tight  fiscal 
constraints . 


EVOLUTION  OF  SATELLITE  CONTROL 

1960.  The  Satellite  Test  Center  (ST C)  is 
activated  on  an  11.4-acre  site  in  Sunnyvale, 
California.  The  STC  is  linked  to  four  tracking 
stations  through  1.2  ki lobit-per-second  landline 
communications.  That  year,  a  total  of  300  TT&C 
contacts  with  satellites  are  supported  by  the  STC. 

1982.  The  Air  Force  Satellite  Control 
Faci lity (AFSCF)  consists  of  multiple  Mission  Control 
Complexes  (MCC's)  at  the  Sunnyvale  site,  linked  to 
twelve  Remote  Tracking  Stations  (RTS)  through  wide¬ 
band  (up  to  1.5  megabits-per-second)  satellite 
communications.  Simultaneous  TT&C  contacts  with 
twelve  spacecraft  is  the  rule.  Almost  95,000  con¬ 
tacts  are  supported  during  the  year. 


A  300-fold  increase  in  satellite  support  with 
only  a  3-fold  increase  in  the  number  of  tracking 
antennas  which  actually  contact  spacecraft  is  of 
itself  a  remarkable  achievement.  Even  more  signif¬ 
icant  is  the  trend  in  support  requirements  as  shown 
in  Figure  1:  spacecraft  support  workload  has 


Ftgwe  1.  The  Incrtatirtt  AFSCF  Worklomt. 
Number  of  contact*  per  year  are  estimates 
through  1967,  actuate  thereafter 


increased  nearly  monotonically  throughout  this  22- 
year  span.  The  AFSCF  has  thus  been  forced  to  im¬ 
plement  network  enhancements  in  an  evolutionary 
fashion  in  order  to  maintain  ongoing  operations 
while  preparing  for  increased  supoort  requirements. 

Early  Enhancements 

Early  AFSCF  network  enhancements  focused  on 
increasing  the  number  of  remote  tracking  sites, 
augmenting  RTS  equipment  complements,  and  increas¬ 
ing  the  number  of  control  consoles  and  computers 
within  the  STC  control  room.  The  primary  objective 
of  these  augmentations  was  to  provide  the  capabil¬ 
ity  for  multiple  TT&C  'control  paths'  from  the  STC 
through  the  RTS's  to  supported  spacecraft,  thereby 
permitting  multiple  simultaneous  contacts.  The 
first  successful  multiple  satellite  operations  were 
conducted  in  support  of  the  Discoverer  program  on 
17  February  1961.  By  the  end  of  1963,  such  opera¬ 
tions  were  routine.  Subsystem  improvements  in¬ 
cluded  RTS  Precision  Long  Range  Tracking  Radars  and 
display  equipment  at  both  the  RTS  and  STC.  Figure 
2  shows  the  1964  system  design. 

Standardi zation 


ual^zed.  No  two  stations  were  identically  config- 
gured,  and  a  variety  of  TT&C  systems  were  used  to 
match  the  peculiar  requirements  of  each  spacecraft 
being  supported.  Such  uniqueness  obviously  limited 
the  support  flexibility  and  efficiency  of  the  total 
network;  it  also  was  increasingly  expensive.  In 
recognition  of  this  problem,  the  Air  Force  con¬ 
ceived  the  concept  of  an  integrated,  standardized 
TT&C  system  for  DoD  spacecraft  support:  the  Space- 
Ground  Link  Subsystem  (SGLS).  Implemented  in  the 
1967-9  time  frame,  SGLS  multiplexed  TT&C  signals 
on  RF  carriers  in  the  1.76-1.84  GHz  (uplink)  and 
2.2-2. 3  GHz  (downlink)  frequencies,  allowing  use  of  a 
common  antenna  for  uplink  and  downlink  transmis¬ 
sions.  Greater  uplink  and  downlink  capacity  was 
achieved,  and  satellite  tracking  accuracy  was 
significantly  improved.  In  conjunction  with  SGLS, 
an  Advanced  Data  System  (ADS)  was  implemented. 

ADS  equipment  installed  at  the  RTS's  included  a 
new  computer  system,  improved  display  and  control 
equipment,  and  new  interface  equipment  to  mate  ADS 
with  existing  RTS  systems.  The  STC  was  expanded 
to  include  a  modernized  (CDC  3800)  computer  system 
and  a  new  display  and  control  system,  thus  allow¬ 
ing  satellite  controllers  at  the  STC  to  exercise 
direct  control  over  their  missions. 


Although  the  enhancements  described  above 
substantially  increased  AFSCF  support  capability, 
early  RTS's  were  still  for  the  most  part  individ¬ 


Two  other  implementation  steps  in  the  late 
1960 ‘ s  furthered  the  standardization  process.  All 
STC  elements  of  control  for  a  particular  program 
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Figure  2.  AFSCF  System  Design  Circa  1964 


or  set  of  programs  were  consolidated  in  Mission 
Control  Complexes,  each  of  which  had  the  necessary 
system  and  personnel  resources  to  support  planning 
for  and  control  of  assigned  missions.  Secondly,  a 
centralized  Scheduling  Control  and  Resource  Allo¬ 
cation  Buffer  Link  (SCRABL)  program  was  developed 
to  provide  a  complete  schedule  of  all  AFSCF  activ¬ 
ities  at  both  the  RTS's  and  STC.  SCRABL-produced, 
detailed,  7-day  schedules  provided  greatly  im¬ 
proved  integration  of  system  maintenance  and  modi¬ 
fication  efforts  into  the  total  AFSCF  activity 
flow,  significantly  increasing  the  system  avail¬ 
ability  for  satellite  support  operations.  The 
scheduling  function  was  part  of  a  centralized 
Range  Operations  organization,  charged  with 
controlling  " common-user *  AFSCF  resources  (e.g., 
the  RTS's)  and  providing  network  services  to  all 
MCC’s.  The  1970  AFSCF  had  thus  virtually  isolated 
program-uniqueness  to  the  MCC's,  with  standardi¬ 
zation  of  other  network  assets  for  maximum  respon¬ 
siveness.  Figure  3  shows  the  1970  system  design. 

Meeting  the  Megabit  Challenge 

The  1970’s  might  be  termed  the  satellite 
Information  Explosion  Era  for  the  AFSCF.  Advances 
in  spacecraft  mission  sophistication  and  satellite 
technology  led  to  great  increases  in  data  rates, 
which  the  AFSCF  was  required  to  route  and  process 
in  real-time  or  near  real-time.  (Such  data  was 
previously  processed  at  the  RTS  and  relayed  to  the 


STC  at  1.2  kilobits  per  second,  with  obvious  im¬ 
plications  on  data  freshness.)  A  limited  capa¬ 
bility  for  real-time  data  transfer  was  obtained  in 
1972  through  implementation  of  an  Interim  Wideband 
Communications  System  (IWCS),  which  linked  the 
Guam  and  Hawaii  tracking  stations  to  the  STC 
through  the  Defense  Satellite  Communications  Sys¬ 
tem  (DSCS).  Real-time  relay  of  analog  data  at  one 
MHz  could  be  achieved. 

A  much  more  comprehensive  wideband  communica¬ 
tions  upgrade  effort  was  begun  in  1975,  bearing 
the  somewhat  cumbersome  name  of  the  Defense 
Satellite  Communications  System/Satellite  Control 
Facility  Interface  System  (DSIS).  DSIS  employed 
asynchronous  multiplexer  and  demultiplexer  equip¬ 
ment  to  combine  signals  from  a  variety  of  sources 
(at  either  the  STC  or  RTS),  then  to  modulate  or 
demodulate  the  combined  signals  onto  or  from  70 
MHz  interface  carriers  relayed  through  the  DSCS 
satellites.  Upon  completion  of  the  DSIS  program 
in  1978,  digital  data  could  be  forwarded  from  the 
STC  to  an  RTS  at  up  to  192  Kb/s,  and  returned  from 
the  RTS  to  the  STC  at  up  to  1.53  Mb/s. 

One  significant  advantage  of  DSIS  implementa¬ 
tion  was  the  capability  to  centralize  TT&C  data 
processing  at  the  STC,  rather  than  having  to  split 
processing  functions  between  the  STC  and  RTS's. 
However,  the  CDC  160-A  'Bird  Buffer"  telemetry 
processing  computers  at  the  STC  were  incapable  of 


Figure  3.  AFSCF  System  Design  Clree  1970 
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providing  the  throughput  necessary  to  do  the  total 
processing  job.  In  parallel  with  OSIS  implementa¬ 
tion,  replacement  of  the  160-A  computers  was  under¬ 
taken.  A  key  ground  rule  of  the  replacement  pro¬ 
cess  was  preservation  of  the  several  million  words 
of  code  being  executed  on  the  160-A' s--recoding  was 
unacceptable  both  from  cost  and  operational  risk 
viewpoints.  The  resulting  replacement  design  fea¬ 
tured  a  Varian  73  microprogrammable  processor 
which  emulated  the  logic  of  the  predecessor  COC 
machines,  thus  preserving  the  code,  while  achieving 
7:1  improvement  in  processing  throughput.  This 
design  provided  computing  capability  within  the  STC 
fully  compatible  with  the  higher  data  rates  of  OSIS. 

The  Future:  Automation 


launch  vehicle  capability  with  a  series  of  evolving 
objectives: 

•  Operational  capability  for  single  flight 
support 

•  Dual  flight  support  capability 

•  The  capability  to  support  secure  DoD 
flights  (termed  "Controlled  Mode") 

•  The  capability  to  support  sophisticated 
on-board  experiment  packages  from  a 
"Payload  Operations  Control  Center" 

To  meet  the  requirements  of  these  four  opera¬ 
tional  phases,  JSC  ground  control  capability  has 
been  planned  for  and  is  being  implemented  in  a 
series  of  evolutionary  steps. 


By  1979,  the  above  evolutionary  enhancements 
allowed  the  AFSCF  to  provide  near-flawless  support 
of  greatly  increased  satellite  support  require¬ 
ments.  However,  network  operations  continued  to 
be  manpower- intensive.  Support  projections  for 
the  1980' s  and  1990' s  also  indicated  network  sat¬ 
uration  was  rapidly  approaching.  The  AFSCF  there¬ 
fore  undertook  a  sweeping  TT&C  modernization  effort 
in  1979.  This  program,  termed  Data  Systems  Modern¬ 
ization  (DSM) ,  has  as  its  key  requirements: 

•  Centralized  data  processing 

•  Modern  flight  support  hardware  systems 

•  Modern,  ADA-based  software  development 

•  Simplified  operations  for  reduced 
staffing 

DSM  hardware  and  software  development  is  currently 
underway,  with  MCC  initial  operational  capabilities 
scheduled  to  be  phased  in  throughout  the  mid-1980's. 
When  completed,  DSM  will  allow  current  STC  and  cer¬ 
tain  current  RTS  TT&C  operations  to  be  fully  con¬ 
trolled  from  individual  MCC's.  Automation  of  net¬ 
work  resources  scheduling  is  also  planned.  Finally, 
a  parallel  modernization  of  the  RTS's  is  planned 
for  the  mi d- 1980 's  to  further  automate  RTS  opera¬ 
tions.  Exhaustive  Air  Force  planning  for  these 
efforts  has  focused  on  carefully  phased  transition 
to  modernized  systems,  to  ensure  that  new  capa¬ 
bilities  will  be  brought  online  without  impacting 
continuing  operations. 

MANNED  SPACEFLIGHT  EVOLUTION 

In  contrast  to  satellite  operations,  manned 
spaceflight  support  through  the  Apollo  era  may  be 
fairly  characterized  as  a  series  of  'new  start' 
developments.  A  substantial  base  of  software 
applications  code  (e.g.,  trajectory  analysis)  has 
been  used  with  modest  modification  throughout  the 
Mercury,  Gemini,  Skylab,  Apollo,  and  early  Space 
Transportation  System  (STS)  programs.  Similarly, 
some  hardware  legacy  was  maintained.  However,  each 
of  these  programs  had  unique  mission  objectives 
which  were  reflected  in  significantly  dissimilar 
TT&C  support  requirements  and  accompanying  systems 
at  NASA's  Johnson  Space  Center  (JSC). 

The  STS  System,  however,  was  from  its  incep¬ 
tion  planned  and  implemented  as  a  truly  operational 


Figure  4  shows  the  increase  in  one  area  of  STS 
operations,  flight  display,  control,  and  communica¬ 
tions  functions,  as  STS  operations  evolve  from 
single-flight  control  through  payload  operations. 

As  was  the  case  with  the  AFSCF,  the  basic  philoso¬ 
phy  of  STS  modernization  throughout  this  period 
has  been  the  preservation  of  existing  equipment  and 
software  while  developing  new  capabilities.  The 
example  of  Figure  4  is  mirrored  by  equivalent  evol¬ 
utionary  increases  in  the  technical  equipment  and 
supporting  software  required  for  other  flight  con¬ 
trol  functions;  for  flight  planning;  and  for  flight 
preparation  activities  such  as  simulation.  Through 
such  evolutionary  modifications,  NASA  has  been  able 
to  continue  to  plan  for  and  execute  successively 
more  complex  missions,  while  retaining  operational 
capability  to  fully  support  current  mission  efforts. 
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INTERNETTING 

Historically,  the  development  of  Air  Force 
and  NASA  space  support  systems  has  been  kept  separ¬ 
ate  as  a  matter  of  national  space  policy.  With  the 
advent  of  the  STS  as  the  common  launch  vehicle  for 
both  DoD  ar.u  NASA  spacecraft,  it  became  appropriate 
to  combine  NASA  and  Air  Force  Space  Mission  support 
assets  into  a  truly  common  user  network  for  all 
United  States  space  programs. 
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Initial  efforts  to  combine  Air  Force  and  NASA 
control  systems  focused  on  the  use  of  Air  Force 
facilities  to  support  the  initial  phases  of  the  STS 
program.  Specific  modifications  to  the  Air  Force's 
Electronics  Systems  Test  Laboratory  and  the  Remote 
Vehicle  Checkout  Facility  (RVCF)  at  Kennedy  Space 
Center  (KSC)  were  made  to  permit  detailed  pre¬ 
launch  Space  Shuttle  and  Space  Shuttle  payload  com¬ 
patibility  testing.  Major  modifications  were  also 
made  to  both  the  STC  and  to  all  RTS's  to  enable 
shuttle  TT&C  support  to  be  provided  throuqh  both 
the  AFSCF  network  and  NASA's  Ground  Spaceflight 
Tracking  and  Data  Network  (GSTDN). 

Figure  5  shows  the  internetting  of  Air  Force 
and  NASA  Control  networks  created  by  these  initial 
modifications.  Support  of  OoD  and  NASA  satellites 
remained  the  separate  responsibilities  of  DoD  and 
NASA  networks.  The  Vandenberg  Air  Force  Base 
(VAFB)  and  KSC  launch  control  complexes  (called 
"LCC's"  at  Kennedy  and  "SLC's"  at  Vandenberg)  con¬ 
tinued  to  serve  both  DoD  and  NASA  launch  missions. 
The  key  new  internet  was  an  STS  TT&C  path  from  the 
RTS  through  the  STC  to  NASA's  space  mission  commun¬ 
ications  center  at  Goddard  Space  Flight  Center 
(GSFC),  then  on  to  JSC.  Successful  implementation 
of  this  new  NASA-OoD  interface  allowed  NASA  Mission 
Controllers  significantly  enhanced  TT&C  access  to 
the  Shuttle  during  critical  mission  phases. 


Figures.  Air  Force  ■  NASA  Control 
Network  Internetting  Circe  1981 


The  next  major  STS  modification  to  the  AFSCF 
was  the  development  of  the  Inertial  Upper  Stage 
(IUS)  Mission  Control  Center  at  the  STC.  The  IUS 
was  developed  by  the  Air  Force  as  a  booster  stage 
to  allow  payloads,  initially  launched  from  the 
Shuttle,  to  reach  higher  orbital  altitudes.  With 
the  IUS  MCC  operational,  Air  Force  and  NASA  control 
networks  could  cooperatively  support  satellite 
missions  throughout  the  launch,  boost,  and  on-orbit 
phases.  An  excellent  example  of  such  multi-network 
support  capability  is  the  1983  launch  of  the  Track¬ 
ing  and  Data  Relay  Satellite  System  (TDRSS).  The 
TDRSS  satellite,  basically  a  NASA  asset,  was 
launched  from  a  NASA  Shuttle,  and  boosted  into 
orbit  on  an  Air  Force  IUS.  Throughout  the  flight 
of  the  Shuttle,  the  IUS,  and  the  TDRSS  satellite 
itself,  both  Air  Force  and  NASA  ground-control  net¬ 
works  were  actively  involved  in  following  the  pro¬ 
gress  of  the  TDRSS  mission.  The  TDRSS  flights  also 
demonstrated  the  capabilities  of  direct  wideband 
data  links  developed  between  the  STC  and  NASA's 


Johnson  Space  Center  (JSC),  as  well  as  the  develop¬ 
ment  of  shuttle  telemetry  data  processing  capabil¬ 
ity  within  the  STC. 

Development  of  the  Air  Force  Space  Control  Network 
(AFSCN) 

Continued  internetting  of  NASA  and  Air  Force 
assets  was  obviously  an  effective  and  efficient  way 
to  combine  previously  separate  capabilities  into  an 
integrated  space  mission  support  system.  In  addi¬ 
tion,  certain  functions  of  previously  dedicated 
satellite  systems  showed  promise  for  "common  user" 
applications  to  multiple  satellite  support.  The 
resulting  integrated  space  support  network  has 
been  termed  the  Air  Force  Space  Control  Network 
(AFSCN).  The  AFSCN  combines  assets  of  the  AFSCF, 
of  NASA,  and  of  previously  dedicated  networks  such 
as  the  Global  Positioning  System  (GPS)  into  a  truly 
integrated  space  support  network. 

The  heart  of  the  AFSCN  is  the  Consolidated 
Space  Operations  Center  (CSOC),  to  be  located  near 
Colorado  Springs,  Colorado.  Figure  5  showed  the 
limited  internet  of  Air  Force  and  NASA  space  assets 
in  the  1981  time  frame;  Figure  6  redepicts  the  net¬ 
work  in  the  1990  time  frame,  with  the  CSOC  opera¬ 
tional.  The  CSOC  itself  consists  of  both  a  satel¬ 
lite  control  center  (analogous  to  the  current  STC), 
and  a  secure  DoD  shuttle  support  capability.  CSOC 
communications  systems  link  the  facility  to  both 
current  Air  Force  and  NASA  tracking  networks,  in¬ 
cluding  the  TDRSS  system.  In  addition,  the  facil¬ 
ity  has  been  designed  to  accommodate  such  dedicated 
satellite  support  systems  as  GPS  and  the  new 
MILSTAR  communications  system.  Through  the  inter¬ 
netting  of  such  dedicated  systems  with  the  common 
user  network  of  the  AFSCN,  greater  operational 
flexibility  and  significantly  improved  survivabil¬ 
ity  of  these  dedicated  networks  is  provided.  When 
operational  requirements  of  the  dedicated  networks 
permit,  assets  of  those  networks  may  also  be  used 
to  further  enhance  the  common-user  capabilities  of 
the  AFSCN  in  supDorting  other  satellite  programs. 


Figure  6.  The  Air  Force  Space 
Control  Network  Circe  1990 
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EVOLUTIONARY  PROCUREMENT  METHODOLOGIES 

The  evolution  of  the  space  support  systems 
described  above  has  significantly  enhanced  the 
overall  interoperability  and  utility  of  all  U.S. 
space  systems.  The  cost,  however,  of  space 
development  has  been  of  continuing  concern  to  the 
Air  Force--in  particular,  major  cost  growth  during 
development  as  a  result  of  requirements  changes. 
Under  the  guidance  of  both  General  Slay  and  General 
Marsh,  as  commanders  of  the  Air  Force  Systems 
Command  (AFSC),  a  major  effort  has  been  undertaken 
to  procure  space  C^  systems  in  an  environment  of 
maximum  competition  and  minimum  cost-growth.  Two 
specific  procurement  strategies  have  been  used: 

•  Use  of  a  procurement  procedure,  described 
in  0MB  Circular  A- 109,  which  involves  com¬ 
petitive  definition  or  design  study  phases 
before  development  contract  action. 

•  The  use  of  a  block  or  incremental  support 
capability  strategy  in  development  con¬ 
tracts  to  allow  incorporation  of  evolving 
requirements  with  minimum  cost  impact. 

The  "A-109  type"  procurement  methodology  is  an 
approach  of  two-or-more  phases.  It  is  modeled 
after  the  procedures  established  by  DoD  for  the 
procurement  of  major  weapons  systems.  The  princi¬ 
ple  behind  the  A-109  methodology  is  to  fund  two  or 
more  contractors  for  the  competitive  development 
of  a  weapons  system  prototype  to  satisfy  a  given 
requirement  or  mission  need.  When  a  subsequent 
single  production  contract  is  awarded,  costs  are 
known  and  risk,  technical  as  well  as  cost  and 
schedule,  is  substantially  reduced. 

When  associated  with  space  C3  programs,  the 
A-109  type  definition  or  design  procurement  re¬ 
sults  in  development  of  specifications,  plans,  and 
design  concepts  rather  than  a  prototype.  Once  the 
chosen  definition  phase  contractors  have  completed 
their  tasks,  the  Government  has  the  capability  of 
melding  the  results  into  an  improved  specification 
for  the  development  phase  RFP.  The  Air  Force 
therefore  gains  the  expertise  of  all  definition 
phase  contractors  in  analyzing  requirements  and 
design  alternatives.  Resulting  development  phase 
proposals  therefore  provide  increased  confidence 
in  validity  of  the  technical  approach  and  the 
accuracy  of  costs. 

The  second  major  strategy  of  the  evolutionary 
development  approach  is  the  implementation  of 
major  space  systems  in  a  truly  evolutionary  manner. 
A  basic  capability  is  contracted  for  in  the  initial 
phase  of  a  development  effort,  with  subsequent 
capabilities  planned  as  options  to  the  basic  con¬ 
tract.  Through  the  use  of  such  options  (termed 
"blocks"  or  "incremental  support  capabilities"), 
the  Air  Force  has  the  opportunity  to  observe  dev¬ 
elopment  contractor  performance  and  to  verify 
long-term  requirements  before  commiting  to  signif¬ 
icant  additional  expenditures  for  complete  capa¬ 
bility  development.  This  combination  of  A-109 
procurement  and  incremental  development  contract¬ 
ing  has  been  used  or  is  being  contemplated  for  use 
by  AFSC  in  the  DSM  procurement,  in  the  CSOC  Com¬ 


munications  contract,  and  in  the  CSOC  Shuttle 
Operations  and  Planning  Complex  contract. 

The  basic  advantages  to  the  Air  Force  of  the 
use  of  A-109  and  block  development  approaches  to 
space  support  C^  programs  are  obvious.  The  defin¬ 
ition  segment  allows  the  Government  to  identify 
program  risks,  stimulate  competition,  and  gain  the 
best  technical  solution  for  a  given  set  of  require¬ 
ments.  The  development  segments  allows  for  an 
early  initial  operational  capability,  for  continued 
analysis  of  high  risk  requirements,  for  the  capa¬ 
bility  to  infuse  technology  as  it  becomes  availa¬ 
ble,  for  more  adaptable  funding  profiles,  and  for 
continued  evolution  of  the  required  capabi lity  over 
a  much  longer  time  span.  There  are,  however, 
challenges  to  both  the  Air  Force  and  contractor 
community  when  this  methodology  is  applied.  In  a 
multiple-contractor  definition  phase  effort.  Air 
Force  technical  monitors  must  be  careful  to  main¬ 
tain  the  proprietary  nature  of  innovative  techni¬ 
cal  solutions  and  prevent  "technical  leveling" 
between  competing  contractors.  Additionally,  a 
manpower  burden  is  placed  upon  the  Air  Force  to 
maintain  full  awareness  of  multiple  competing 
design  efforts.  From  the  contractors  viewpoint, 
a  careful  balance  of  effort  is  required  between 
performance  of  definition  phase  tasks  (e.g.,  speci¬ 
fication  development)  and  preparation  for  the 
development  phase  competition.  Once  the  develop¬ 
ment  phase  contract  itself  is  awarded,  both  the 
Air  Force  and  the  contractor  must  work  closely  and 
cooperatively  together  to  insure  that  changing 
requirements,  when  identified,  are  implemented  in 
the  appropriate  block  or  incremental  support  capa¬ 
bility  to  provide  a  truly  cost  and  technically 
effective  solution. 

CONCLUSIONS 

The  evolution  of  Air  Force  space  mission 
support  C^  has  a  rich  history  and  a  promising 
future.  As  Air  Force  and  NASA  ground  and  space 
assets  are  melded  into  a  truly  national  space  sys¬ 
tem,  significant  opportunities  exist  for  technical 
innovation  and  cost  effectiveness  in  the  satisfac¬ 
tion  of  national  space  objectives.  These  oppor¬ 
tunities  are  matched  by  equally  significant 
challenges  to  efficiently  implement  change  without 
degrading  ongoing  operations.-  Changes  in  acquisi¬ 
tion  methodologies  provide  additional  challenges 
to  both  the  contractor  community  and  the  AirForce; 
but  working  together,  the  Air  Force-contractor 
team  shall  continue  to  do  what  it  has  done  in  the 
past--get  the  job  done,  and  get  it  done  right. 
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ABSTRACT 


U.S.  military  communications 
satellites  can  provide  an  impressive 
capability  for  command  and  control. 
Whether  the  combat  forces  will  be  able 
to  make  effective  use  of  this 
capability  depends  on  the  operational 
management  of  the  systems.  Today, 
control  of  COMSAT  systems  optimizes 
their  use  to  support  a  single  mission 
or  class  of  missions.  In  conflict  it 
will  be  necessary  to  allocate  capacity 
based  on  mission  priority  rather  than 
peacetime  operational  concepts.  A 
satellite  control  network  tied  to  the 
JCS  through  the  Space  Defense 
Operations  Center  would  allow  rapid 
reallocation  of  capability  to  support 
wartime  and  crisis  requirements  without 
jeopardizing  the  role  of  the 
operational  manager. 
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INTRODUCTION 

"The  Navy  has  the  finest  peacetime 
communications  system  in  the  world, 
through  the  FLTSATCOM  system."  This  oft 
repeated  claim  highlights  both  the 
strength  and  the  weakness  of  military 
satellite  communications  (MILSATCOM). 
They  are  effective,  reliable  and 
efficient.  We  have  seen  the  Fleet 
Satellite  Communications  (FLTSATCOM) 
system  bring  word  of  the  shootdown  of 
two  jets  over  the  Gulf  of  Sidra  to  the 
Chief  of  Naval  Operations  within  two 
minutes  of  the  attack  —  exactly  what 
the  Navy  intended  of  the  system  when 
they  wrote  the  specifications  more  than 
a  decade  before.  We  have  seen  the  Air 
Force  Satellite  Communications  System 
(AFSATCOM)  allow  Headquarters  Strategic 
Air  Command  maintain  positive  control 
over  a  B-52  participating  in  an 
exercise  halfway  around  the  world.  We 
have  seen  the  Defense  Satellite 
Communications  System  (DSCS) 
revolutionize  the  handling  of  wideband 
data  between  overseas  locations  and  the 
United  States.  In  these  and  countless 
other  applications  we  understand  our 


systems  and  are  experienced  in  making 
them  perform  as  required. 

On  the  other  side  of  the 
operational  coin,  we  have  little 
experience  operating  the  systems  under 
stressed  conditions  —  conditions  where 
the  satellites  are  being  jammed,  or 
there  is  a  sudden  decrease  in  capacity 
available  or  increase  in  demand  for 
support.  Peacetime  performance  is 
certainly  essential,  and  obtaining  more 
bits  for  the  buck  is  as  important  to  a 
communications  system  as  more  bang  for 
the  buck  is  to  a  weapon  system.  But  the 
reason  for  military  acquired,  owned  and 
operated  systems  is  their  ability  to 
perform  in  crisis  or  war.  Without  that, 
we  might  as  satisfy  all  our  long  haul 
SATCOM  requirements  with  leased 
commercial  satellites  and  terminals. 

Future  SATCOM  systems  such  as  the 
Military  Strategic,  Tactical  and  Relay 
(MILSTAR)  system  are  being  designed  to 
provide  service  in  a  hostile 
environment.  The  anti- jam  capability  of 
DSCS  III  is  a  substantial  improvement 
over  anything  in  the  inventory,  and 
with  the  spread  spectrum  modem  will 
offer  assurance  that  the  minimum 
essential  communications  between  heavy 
terminals  will  get  through  —  once  all 
the  satellites  and  AN/USC-28  equipment 
are  in  place.  These  projections, 
however,  don't  help  the  warfighter 
today . 

We  learned  during  some  of  the 
crisis  and  contingency  operations  of 
the  last  five  years  that  the  systems  we 
have  can  do  things  the  original 
designers  never  expected,  when  operated 
with  imagination  and  careful  planning. 
The  challenge  facing  the  MILSATCOM 
operator  is  to  make  this  crisis 
capability  available  on  a  rapid  basis 
without  disrupting  the  rest  of  the 
system,  including  high  priority 
peacetime  users,  to  an  unacceptable 
level . 

This  paper  will  review  the 
operational  concepts  for  MILSATCOM 
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systems  in  general  and  for  the  three 
primary  systems:  AFSATCOM,  FLTSATCOM 
and  DSCS.  It  wrll  assess  how  they  might 
perform  if  pressed  in  a  crisis  or 
wartime  situation,  and  propose  how  this 
capability  could  be  improved  at  little 
cost.  I  appreciate  the  assistance  of 
the  Operational  Managers  (OM)  for  the 
three  systems,  and  of  the  Army 
Satellite  Communications  Agency  for 
supplying  data  on  the  Ground  Mobile 
Forces  SATCOM  system.  I  am  sure  there 
are  cases  where  I  have  taken  good  data 
and  either  misunderstood  or  wrongly 
applied  what  was  said.  The 
responsibility  for  these  errors  is 
mine . 


CONTROL  OF  MILSATCOM  SYSTEMS 

JCS  MOP  ♦  178:  "MILSATCOM  Systems" 

The  primary  policy  guidance  for 
operations  of  MILSATCOM  systems  is  the 
JCS  Memorandum  of  Policy  Number  178, 
"Military  Satellite  Communications 
Systems".  This  guidance  has  evolved 
over  several  iterations  to  keep  pace 
with  the  improvements  in  SATCOM 
systems.  The  1978  revision,  which  is 
the  most  current  version,  defines  the 
responsibilities  of  the  operational 
managers  and  the  Joint  Chiefs  of  Staff 
(JCS).  The  JCS  retains  the  authority  to 
approve  and  direct  support  to  new  users 
in  crisis  or  war,  while  the  OM  is 
allowed  considerable  latitude  in 
peacetime,  and  in  the  manner  in  which 
additional  users  are  included  in  crisis 
or  war.  In  general,  the  MOP  prioritizes 
allocation  of  capacity  in  the  following 
order: 

1.  National  Command  Authorities 

2.  Joint  Chiefs  of  Staff 

3.  Commanders  in  Chief  (CINCs) 

4 .  Component  Commands  of  CINCs 

5.  Other  operational  forces 

6.  Other  users 

MILSATCOM  systems  are  divided  into 
two  types,  those  under  the  control  of  a 
single  military  department,  called 
"Service-managed"  and  those  under  joint 
control,  or  "Joint-managed".  The  only 
Joint-managed  system  is  the  Defense 
Satellite  Communications  System  (DSCS) 
which  is  operated  by  the  JCS  through 
the  Defense  Communications  Agency 
(DCA) .  The  Service-managed  systems  are 
AFSATCOM  operated  by  the  Air  Force, 
FLTSATCOM  operated  by  the  Navy  and  the 
Ground  Mobile  Forces  (GMF )  system 
operated  by  the  Army.  Each  Service  has 
designated  an  Operational  Manager  for 
day-to-day  control  of  the  systems  (Air 
Force  Communications  Command  / 
Strategic  Communications  Division, 
Naval  Telecommunications  Command  and 


US  Army  Communications  Command, 
respectively).  These  organizations 
respond  to  Service  direction,  or  to  the 
JCS  in  stressed  situations  when  new 
users  are  added  to  the  system.  Under 
these  conditions  most  new  users  would 
be  considered  "JCS  requirements"  with 
Priority  2,  and  would  preempt  lower 
priority  peacetime  traffic  unless  there 
was  sufficient  excess  capacity  to 
accomodate  the  demand. 

The  next  section  will  describe 
the  control  procedures  used  by  the 
various  operational  managers  to  manage 
crisis  situations.  The  GMF  is 

developing  its  own  control  system,  but 
at  this  time  relies  on  the  DCA  control 
network.  GMF  will  not  be  discussed  as  a 
separate  element. 

CONTROL  IN  CRISIS 

AFSATCOM 

The  management  for  AFSATCOM  flows 
from  the  JCS  to  the  Chief  of  Staff, 
USAF  as  the  Executive  Agent,  then  to 
Air  Force  Communications  Command  and 
the  Strategic  Communications  Division 
as  Operational  Manager  (OM).  The  OM  has 
published  the  operating  procedures  in  a 
"System  Operating  Policy  and  Procedure" 
(SOPP)  which  has  been  distributed  to 
all  the  unified  and  specified  commands, 
joint  agencies  and  several  hundred 
service  organizations.  The  SOPP 
describes  the  categories  of  users  as 
Approved  and  Unapproved,  and  within  the 
first  group  as  Full  Period,  Scheduled 
and  Unscheduled.  An  organization  with 
crisis  responsibilities,  such  as  the 
Joint  Communications  Support  Element, 
would  be  carried  as  an  Approved 
Unscheduled  user  —  someone  who  had  an 
operational  concept  approved  by  the  JCS 
and  included  in  AFSATCOM  planning,  but 
couldn't  predict  in  advance  when,  where 
or  in  what  quantity  capacity  would  be 
needed.  The  OM  carries  all  the 
necessary  technical  information  in  its 
data  base,  and  can  accomodate  requests 
for  service  on  short  notice  without  any 
additional  JCS  involvement. 

Unapproved  users  are  those  whose 
intended  use  of  the  system  has  not  been 
formally  approved.  This  may  be  because 
they  are  an  R&D  organization  with 
infrequent  demands,  or  because  they  are 
responding  to  a  crisis  which  requires 
satellite  communications  under 
conditions  that  had  not  been  foreseen. 
The  SOPP  provides  for  telephone 
coordination  of  emergency  requests,  and 
for  support  in  accordance  with  the 
priorities  in  MOP  178. 


The  system  design  for  AFSATCOM 

includes  single  access  and  multiple 

access  channels.  The  5  khz  narrowband 

(NB)  channels  are  half-duplex  and  can 
support  only  one  user  at  a  time. 
Several  terminals  can  share  the 
channel,  but  only  on  a  time-division 
multiple  access  basis.  This  TDMA  can  be 
automatic  if  the  terminal  is  equipped 

with  the  proper  control  modem,  or  based 
upon  user  dicipline.  In  either  case, 
because  of  the  low  data  rates  available 
(75  bps)  the  most  common  means  of 
allocation  of  NB  capacity  is  to  assign 
a  full  channel  to  a  network  or  sub-net. 
Because  the  satellite  is  channelized 
with  specific  power  allocations  for 
each  channel,  the  user  is  assured  of 
both  bandwidth  and  EIRP. 

Recent  work  by  SCD  has 
demonstrated  the  ability  to  support 
higher  data  rates  on  some  of  the  NB 
channels  on  FLTSATCOM.  While  this 
probably  won't  affect  the  concept  of 
assigning  single  nets  to  channels,  it 
may  alleviate  possible  conflicts  on  the 
wideband  channel . 

Each  FLTSATCOM  satellite  carries 
one  500  khz  channel  in  addition  to  the 
12  NB  AFSATCOM  channels  and  10  25  khz 
Navy  FLTSATCOM  channels.  The  primary 
use  of  the  500  khz  wideband  (WB) 
channel  is  to  support  multiple  75  bps 
teletype  links.  All  AFSATCOM  command 
posts  are  equipped  with  8-ary  FSK 
modems,  and  the  channel  can  support  at 
least  14  half-duplex  accesses 
simultaneously  in  the  absence  of  other 
channel  users.  Competition  for  the 
channel  arises  because  it  has  high 
power  and  enough  bandwidth  to  support 
high  data  rate  communications .  However, 
the  design  is  such  that  downlink  power 
is  allocated  among  links  in  proportion 
to  the  uplink  power  —  hence  a  small 
number  of  high  power,  high  data  rate 
users  can  "crowd  out"  other  links.  The 
situation  is  not  much  different  from 
that  faced  by  DCA  in  allocating  access 
to  the  DSCS  satellites. 

The  assignments  of  users  to  the  WB 
channel  is  done  in  the  same  manner  as 
for  NB,  and  the  channels  are  monitored 
to  ensure  terminals  are  operating  at 
the  proper  power  and  frequency.  Because 
of  the  flexibility  of  the  WB  channel  — 
virtually  any  UHF  terminal  operated  by 
the  US  military  can  be  used  —  it  is  in 
constant  demand  for  unscheduled  users. 
Most  obtain  authorization  before  using 
the  system,  but  some  do  not.  This 
points  out  one  of  the  most  difficult 
problems  in  SATCOM  management:  it  is 
difficult  to  monitor  access,  difficult 
to  locate  unauthorized  users,  and  short 


of  a  physical  attack  nearly  impossible 
to  force  someone  off  the  system.  The 
multi-beam  antenna  of  DSCS  III  will 
help  solve  the  problem  for  that  system, 
but  for  earth  coverage  systems  such  as 
AFSATCOM  and  FLTSATCOM  the  Operational 
Manager  is  nearly  helpless. 

Of  the  three  major  MILSATCOM 
systems,  AFSATCOM  has  the  most 
experience  in  supporting  crisis  and 
other  unscheduled  requirements.  This  is 
partly  because  the  system  is  flexible, 
and  can  be  used  by  any  UHF  SATCOM 
terminal.  However,  it  is  also  because 
the  system  was  designed  with  some 
excess  capacity.  This  excess  is  not  a 
matter  of  gold  plating:  under  certain 
conditions  every  channel  of  every 
satellite  in  sight  of  critical 
strategic  areas  would  be  filled.  These 
conditions  drove  the  design,  because 
the  wartime  requirements  for  global 
strategic  command  and  control  are  the 
reason  the  system  was  built.  Since  the 
situations  which  would  saturate  the 
system  would  almost  never  occur  in 
peacetime  or  crisis,  the  OM  has  some 
flexibility  to  apportion  the  available 
channels  to  other  users  as  long  as  he 
can  assure  the  Approved  Full  Period  and 
Scheduled  users  the  system  will  be 
available  when  they  need  it.  Much  of 
the  development  of  operational 
contingency  terminals  has  been  a  result 
of  success  in  using  AFSATCOM  capability 
in  exercises  and  demonstrations  of 
crisis  response. 

Because  of  the  experience  in 
dealing  with  unapproved  high  priority 
users,  AFSATCOM  is  more  likely  than 
DSCS  or  FLTSATCOM  to  be  able  to  handle 
without  major  disruption  the  rapid 
changes  in  operations  which  would  be 
likely  in  a  crisis.  Whether  this  will 
continue  to  be  the  case  as  more 
approved  users  are  equipped  with 
terminals  and  the  system  fills  up  in 
peacetime  remains  to  be  seen.  The  SOPP 
suffers  from  the  imprecision  of  MOP  178 
in  that  it  will  be  difficult  to 
prioritize  among  "high  priority"  users. 
If  many  of  the  crisis  users  have 
terminals  which  require  large  shares  of 
the  satellite  power  and  high  data  rates 
which  force  them  to  the  WB  channel  — 
as  is  likely  since  this  describes  as 
portable  secure  voice  system  —  the 
confidence  of  the  OM  in  preparing  for 
crisis  operations  may  soon  erode. 

FLTSATCOM 

The  FLTSATCOM  is  the  oldest  of  the 
service-managed  systems.  It  includes 
terminals  on  board  all  Navy  ships  and 
many  shore  facilities.  The  space 


segment  includes  channels  on  the  four 
FLTSATCOM  satellites,  GAPFILLER  and 
eventually  LEASAT.  The  operational 
concept  of  FLTSATCOM  is  much  like  that 
of  DSCS  in  that  the  users  who  are  on 
the  system  in  peacetime  are  assumed  to 
be  the  same  as  those  in  crisis  or 
wartime.  From  a  technical  viewpoint, 
the  system  is  more  like  AFSATCOM  in 
that  channels  are  assigned  to  specific 
networks,  and  have  protected  EIRP  and 
bandwidth . 

Tna  OM  for  FLTSATCOM  is  the  Navy 
Telecommunications  Command  (NAVTELCOM), 
with  the  CNO  as  Executive  Agent.  In 
many  respects  FLTSATCOM  is  operated  as 
a  part  of  the  general  purpose  Naval 
Telecommunications  System  (NTS).  It  is 
tied  into  several  automated  information 
exchange  systems,  and  the  focal  points 
for  day-to-day  operations  are  Naval 
Communications  Area  Master  Stations 
( NAVCAMS )  . 

Because  FLTSATCOM  is  so  essential 
to  peacetime  communications  among  ships 
and  ship-to-shore,  there  is  little 
planned  flexibility  to  accomodate  other 
users.  All  channels  on  all  satellites 
are  assigned  to  a  specific  mission: 
Fleet  Broadcast,  Command  Ship  Secure 
Voice,  Common  User  Digital  Information 
Exchange  System,  Tactical  Intelligence 
Subsystem,  etc.  Nevertheless,  the 
Operational  Concept  and  Procedures 
(NTP-2 )  acknowledges  that  "there  will 
be  occasions  when  some  manipulation  of 
SATCOM  capabilities  and  services  will 
be  required  to  respond  effectively  to 
the  demands  for  service  generated  by 
crisis/contingency  operations".  The 
manner  in  which  the  manipulation  will 
take  place  depends  on  whether  the 
requirements  are  Navy  or  non-Navy. 

The  Fleet  Commander  in  Chief, 
e.g.,  CINCPACFLT,  is  responsible  for 
direction  and  support  of  naval  forces 
operating  at  sea.  This  includes  some 
tactical  communications  functions 
performed  by  NAVTELCOM.  In  the  case  of 
FLTSATCOM,  the  NAVCAMS  which  control 
each  satellite  operate  under  the 
direction  of  the  theater  FLTCINC . 
Within  limits  described  in  the 
operating  procedures,  the  FLTCINC  is 
authorized  and  responsible  to  make 
adjustments  to  the  system  to  support 
changes  in  Navy  requirements.  This  may 
include  preemption  of  circuits, 
activation  of  spare  terminals  or 
off-loading  networks  to  other 
satellites . 

The  situation  for  non-Navy 
requirements  is  not  so  clear.  To  quote 
NTP-2,  "It  can  be  anticipated,  however, 


that  under  certain  crisis  conditions, 
the  Navy  will  be  tasked  to  provide 
services,  in  accordance  with  JCS  MOP 
178,  to  support  requirements  of  the 
NCA ,  JCS,  Unified  Commanders,  or 
others.  The  support  of  such  unforeseen 
requirements  may  require  the  temporary 
preemption  and  reallocation  of  one  or 
more  FLTSATCOM  channels  or  GAPFILLER 
accesses.  To  minimize  the  impact  on 
Navy  subscribers,  the  precise  manner  in 
which  such  non-Navy  requirements  are  to 
be  satisfied  will  be  determined  by  CNO 
in  close  coordination  with  COMNAVTELCOM 
and  appropriate  FLTCINCs." 

This  approach  highlights  the 
problem  facing  the  Navy  or  any  other  OM 
who  waits  until  a  crisis  arises  to 
publish  and  exercise  the  approach  to 
accomodate  new  users.  Staffs  at  higher 
headquarters  are  not  well  suited  to 
make  real  time  decisions  on  employment 
of  capability  —  whether  the  OPNAV 
staff  for  FLTSATCOM  or  the  Joint  Staff 
under  the  provisions  of  MOP  178.  In  the 
absence  of  exercises,  peacetime  users 
will  find  it  difficult  to  adapt  to  loss 
of  service.  With  no  clear  guidelines, 
the  crisis  user  will  turn  to  some 
alternative  source  of  SATCOM  capacity, 
or  some  other  communications  media. 
While  that  may  be  effective  in  keeping 
unplanned  users  off  a  system,  it 
probably  will  not  result  in  the  best 
response  to  the  crisis. 

The  heart  of  the  dilemma  facing 
the  FLTSATCOM  OM,  and  the  FLTCINCs,  is 
that  the  satellite  is  extremely  well 
suited  for  crisis  support.  The  nine  25 
khz  UHF  channels  have  more  power  and 
greater  bandwidth  than  the  NB  AFSATCOM 
channels  on  the  same  spacecraft,  and 
can  repeat  most  digital  modulation 
schemes  (PSK,  FSK,  etc.)  and  data  rates 
up  to  9600  baud,  plus  FM  voice.  Only 
the  wideband  channel  in  the  AFSATCOM 
system  has  comparable  power  and 
flexibility.  As  the  population  of 
deployable  terminals  increases  the 
demand  for  support  which  can  only  be 
provided  by  FLTSATCOM  will  increase.  At 
present  it  would  be  very  difficult  for 
the  JCS  or  its  agent  to  determine  the 
impact  of  preempting  existing  FLTSATCOM 
service  to  accomodate  a  new  user.  In  a 
real  crisis,  the  JCS  may  have  to  act, 
even  without  this  knowledge. 

DSCS 

The  DSCS  is  the  only  joint-managed 
system,  and  has  been  operating  for  more 
than  15  years.  Under  MOP-178  the  JCS 
retains  responsibility  for  all  aspects 
of  the  system,  but  delegates  authority 
for  many  of  the  day-to-day  functions  to 
the  Defense  Communications  Agency.  In 
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most  respects,  DCA  serves  as  both 
Executive  Agent  and  Operational  Manager 
for  the  system.  DCA  exercises  control 
through  an  operations  center  in  the 
Washington  area  and  area  centers  in 
Europe  and  the  Pacific  theater. 

Contingency  operations  have  been  a 
part  of  the  DSCS  charter  since  the 
earliest  days.  Terminals  have  been 
maintained  on  short  notice  call-up  for 
deployment  worldwide.  The  prime  purpose 
of  the  contingency  terminals  is  Defense 
Communications  System  (DCS)  extension 
—  providing  temporary  long-haul 
communications  to  an  area  without  good 
service  or  to  replace  service  lost 
through  accident  or  damage.  The 
terminals  are  large  and  expensive,  much 
different  from  the  UHF  terminals  used 
with  AFSATCOM  and  FLTSATCOM .  Even  the 
latest  generation  AN/TSC-86  terminals 
take  a  combination  of  trucks  and 
trailers  to  carry  the  equipment. 

The  fundamental  difference  in 
approach  to  crisis  deployments  between 
DSCS  and  the  Service-managed  systems  is 
also  reflected  in  the  JCS  approval 
process.  For  service-managed  systems 
MOP-178  provides  the  means  for  approval 
of  deployments  and  SATCOM  system 
support.  In  effect,  the  movement  of  the 
terminal  is  controlled  by  the  Service. 
For  DSCS  the  movement  of  the  terminals 
is  controlled  by  another  JCS  policy 
document:  JCS  MOP-167,  "Mobile/Trans¬ 
portable  Communications  Assets 
Controlled  by  the  Joint  Chiefs  of 
Staff*.  If  the  contingency  terminal  can 
be  accomodated  within  existing 
capacity,  the  JCS  need  only  address  the 
terminal  deployment,  while  DCA  assigns 
capacity  for  the  new  user. 

The  expense  of  the  terminals  and 
the  fact  that  the  DSCS  system  provided 
some  crisis-response  capability  with 
organic  resources  has  limited  the 
introduction  of  service-managed  DSCS 
contingency  equipment.  However,  now 
that  the  Army,  Air  Force  and  Marines 
have  acquired  GMF  terminals  which 
operate  through  DSCS  and  which  can  be 
deployed  by  the  Service  in  to  provide 
non-DCS  communications  in  crisis,  the 
DSCS  system  has  also  begun  to  plan  for 
support  of  this  new  class  of  users. 

The  operational  concept  for  DSCS 
is  based  on  assigning  similar  types  of 
terminals  to  specific  channels  on  each 
satellite.  Clustering  of  users  based  on 
the  characteristics  of  their 
communications  allows  for  easier 
balancing  of  requirements.  As  a  result, 
several  tactical  communities,  those 
which  use  small  (usually  eight  foot 
diameter  antenna)  terminals,  are 
assigned  to  the  same  channel . 
Contingency  terminals,  GMF,  White  House 
Communications  Agency  and  other 


tactical  systems  are  all  to  be 
supported  by  one  satellite  transponder 
operating  through  a  multi-beam  antenna. 

The  system  managers  in  DCA  have 
recognized  that  their  system  is  a 
likely  target  for  jamming,  and  that  the 
response  to  jamming  is  not  much 
different  from  handling  additional 
users.  The  jammer  "robs"  power  and 
usable  bandwidth  from  the  approved 
users,  just  as  assigning  new  users  to 
the  system  decreases  the  power  and 
bandwidth  available  for  those  already 
on  the  satellite.  As  a  result,  they 
have  prioritized  the  communications 
using  DCS  restoration  priorities  and 
MOP-178.  In  addition,  the  system 
suffered  several  premature  satellite 
failures  in  the  early  1970s,  and  the  OM 
had  unfortunate  experience  in  dealing 
with  allocation  of  users  following  a 
loss  of  capacity. 

Under  the  conditions  that  exist 
today,  DSCS  is  prepared  to  handle  most 
foreseeable  crises.  This  is  based  on 
their  planning  and  experience,  but  even 
more  on  the  limited  population  of 
terminals.  The  problem  for  DSCS  will 
come  as  the  present  generation  of  GMF 
terminals  comes  off  the  production  line 
and  is  made  available  to  Service 
contingency  support  units.  The 
terminals  will  provide  from  12  to  96 
channels  of  32  kbps  or  48  kbps,  which 
can  carry  data  or  voice.  Obviously,  the 
quality  of  the  communications  is 
exceptional.  They  will  be  an  attractive 
addition  to  the  communications  package 
of  any  joint  task  force  ( jtf )  or  other 
deployed  force.  Under  the  operational 
concepts  for  the  GMF,  the  number  of 
terminals  used  to  support  a  JTF  could 
be  substantial .  One  for  each  component 
headquarters,  one  at  each  Tactical 
Air  Control  System  site,  one  at  each 
major  Army  unit,  etc.  A  deployment  like 
that,  especially  in  a  jammed  situation, 
would  strain  the  capability  of  the 
DSCS  OM. 

Because  the  DSCS  is  under  the 
control  of  the  JCS,  in  theory  the  JCS 
itself  will  be  responsible  for  making 
all  the  SATCOM  approvals  which  force  a 
reallocation  of  capacity  (within  some 
limits,  DCA  has  authority  to  manage  up 
to  the  point  when  an  approved  user  must 
be  denied  service).  The  Organization  of 
the  JCS  lacks  the  expertise  to  perform 
this  task  in  real  time,  and  they  will 
certainly  look  to  DCA  for  technical 
assistance.  The  complexity  of  satellite 
system  management  is  such  that 
technical  issues  cannot  be  divorced 
from  the  operational  implications. 
Whether  DCA  is  the  proper  organization 
to  be  advising  on  crisis  or  wartime 
priorities  and  allocations  is  a 
question  that  each  CINC  must  consider. 


Joint  Control 

The  intent  of  MOP-178  is  that  the 
JCS  will  be  the  final  authority  in  the 
control  of  MILSATCOM  systems .  In  the 
days  when  the  MOP  was  first  drafted 
there  were  few  assets  and  few  users. 
Now  there  are  over  a  thousand  military 
terminals  and  a  dozen  or  more  active 
satellites.  The  problem  is  beyond  the 
scope  of  a  staff  which  looks  at  space 
operations  as  one  of  several  important 
tasks.  In  order  to  properly  advise,  and 
at  times  direct  the  OM,  it  is  essential 
the  JCS  be  supported  by  a  group  which 
understands  all  aspects  of  the  problem: 
the  needs  of  the  warfighters,  the 
capabilities  and  limitations  of 
MILSATCOM  systems,  the  status  of  other 
space  systems,  the  nature  of  the  threat 
and  other  operational  considerations. 

Space  Defense  Operations  Center 

The  Space  Defense  Operations 
center  was  established  in  19  79  to 
provide  exactly  the  kind  of  fusion 
center  described  above.  Since  that  time 
it  has  been  developing  ties  to  the  OM 
of  all  military  space  system,  SATCOM 
and  others.  Its  purpose  has  been  to 
collect  status  and  make  information 
readily  available  to  the  JCS,  CINCs  and 
the  space  system  Operational  Managers. 
While  that  process  is  far  from 
complete,  SPADOC  has  come  along  way 
toward  bringing  diverse  communities 
together . 

The  charter  which  directed  SPADOC 
isn't  clear  how  far  that  Center  should 
go  toward  exercising  control  over  space 
systems.  The  decision  was  made  at  ADCOM 
that  it  was  neither  appropriate  nor 
necessary  for  SPADOC  to  exercise 
day-to-day  control  over  any  space 
system.  SPADOC  will  never  have  the 
expertise  necessary  to  perform  the 
functions  of  an  Operational  Manager. 
However,  the  time  is  approaching  when 
the  JCS  will  have  to  address  how  they 
will  perform  the  functions  retained  by 
them  for  space  operations,  and  whether 
they  should  delegate  some  of  those 
functions  to  a  joint  CINC. 

At  present  the  joint  command  to 
perform  these  kinds  of  functions  does 
not  exist.  They  would  be  beyond  the 
scope  of  the  Aerospace  Defense  Command 
(ADCOM),  even  though  SPADOC  is  one  of 
its  operating  centers.  For  the  JCS  to 
delegate  responsibility  for  space 
support  to  a  Unified  or  Specified 
Command  it  will  be  necessary  either  to 
form  another  command  or  substantially 
^change  the  role  of  an  existing  command. 
For  the  purpose  of  this  discussion,  it 


will  be  assumed  that  a  joint  Space 
Command  has  been  established  with  the 
specific  task  of  assisting  the  other 
USS  commands  by  exercising  JCS 
authority  over  Service  and  Joint- 
managed  space  systems  in  times  of 
crisis  or  national  emergency.  The 
SPADOC  will  be  under  the  operational 
control  of  the  commander  in  chief  of 
that  command  (CINCSPACE).  While  the 
SPADOC  would  have  no  authority  of  its 
own,  the  CINC  would  use  the  Center  and 
crew  as  his  representative  in 

situations  which  do  not  require  his 
personal  participation. 

The  SPADOC  has  or  is  acquiring  all 
the  necessary  physical  attributes  to 
perform  as  the  central  coordinating 
point  for  management  of  MILSATCOM 
systems.  The  Operational  Managers  for 
the  systems  would  retain  responsibility 
for  day-to-day  management,  and  for 
implementation  of  JCS  direction.  SPADOC 
would  pass  this  direction  and  monitor 
status  through  existing  dedicated, 
secure  communications  circuits. 
Requirements  from  the  operating 
commands  would  be  passed  to  OM  under 
current  procedures,  and  SPADOC  would  be 
advised  in  those  cases  where  system 
capability  may  be  impacted  or  more  than 
one  operating  force  may  be  involved. 
Existing  secure  record  and  voice 
communications  between  SPADOC  and  the 
command  centers  for  other  U&S  commands 
would  be  used.  In  addition  to  the 
Center  itself,  SPACECOM  would  bring 
experience  in  several  related  space 
operations  missions. 

Satellite  Surveillance 

Air  Force  Space  Command,  which 
exists  today,  has  the  task  of 
detecting,  tracking  and  cataloging  all 
man-made  objects  in  earth  orbit.  That 
includes  approximately  4,800  objects, 
and  requires  over  30,000  radar  and 
optical  observations  each  day  to  keep 
the  catalog  current.  The  resulting  data 
base  is  an  essential  ingredient  in 
planning  for  future  satellite 
positioning,  since  it  includes  inactive 
payloads  and  other  debris  as  well  as 
active  satellites  which  would  be 
carried  in  frequency  management 
records . 

The  network  aj.so  can  assist  launch 
agencies  by  tracking  the  boost  vehicles 
and  payload  during  all  phases  of 
orbital  insertion.  While  this  may 
duplicate  the  tracking  information 
available  from  telemetry  in  a  nominal 
launch,  it  can  be  invaluable  in  failure 
analysis  when  telemetry  is  lost. 
Further,  in  many  cases  the  resolution 
of  the  systems  is  adequate  to  allow  an 
assessment  of  the  external  shape  of  the 
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satellite  on  orbit. 


Satellite  Protection 

SPACECOM  Ti  responsible  for  the 
protection  of  US  space  systems  from 
hostile  and  natural  threats.  The  same 
surveillance  data  which  generates  the 
catalog  is  used  to  predict  possible 
collisions  in  orbit.  With  the  increased 
density  of  satellites  and  launch  debris 
in  synchronous  orbit,  collision 
avoidance  and  position  management  will 
become  essential  to  the  overall 
effectiveness  of  MILSATCOM  systems. 

The  capability  for  actual 
protection  against  hostile  threat  is 
limited,  but  growing.  As  military 
satellites  are  deployed  with  hardening, 
countermeasure  systems  and  maneuver 
capability,  the  need  for  timely  warning 
of  threat  and  for  coordination  of 
responses  will  increase.  It  is  not 
enough  for  the  OM  of  a  system  to  detect 
a  threat  and  take  appropriate  actions 
to  protect  his  system.  The  implications 
of  the  defense  in  terms  of  decreased 
capability  must  be  assessed  with  clear 
knowledge  of  the  operational  missions 
which  may  be  impacted.  In  many  cases 
the  OM  neither  knows  nor  needs  to  know 
this  information,  but  it  must  be 
considered  in  planning  defensive 
actions.  The  SPADOC  will  have  the 
user's  assessment  of  the  value  of  each 
system  and  component  in  its  data  base, 
and  can  include  these  factors  in  advice 
to  the  OM  and  the  JCS. 

Negation 

National  and  DOD  space  policies 
direct,  within  such  limits  imposed  by 
international  law,  the  continued 
development  of  an  operational  anti¬ 
satellite  capability  to  deter  threats 
to  friendly  space  systems,  and  preserve 
our  right  of  self-defense.  If  it  is 
deployed,  CINCAD  will  exercise 
operational  control  over  the  ASAT  from 
the  SPADOC  and  the  Mission  Control 
Center  in  Cheyenne  Mountain. 

JOINT  OPERATIONS 

The  real  value  of  MILSATCOM 
coordination  through  SPADOC  is  not  so 
much  a  matter  of  changing  the  way  we 
would  apply  existing  assets  as  changing 
the  way  we  think  about  space 
operations.  The  problems  that  would 
arise  in  responding  to  a  crisis  come 
from  years  of  thinking  of  systems  as 
resources  to  be  used  to  satisfy  the 
needs  of  a  small  community  of  users.  A 
Space  Command  would  provide  the  vehicle 
to  focus  on  joint  planning,  joint 
operations,  and  timely  allocation  of 
capability  to  meet  the  needs  of  combat 
forces . 


The  role  of  a  joint  Space  Command 
would  begin  at  the  earliest  part  of  the 
acquisition  process.  CINCSPACE  would 
provide  a  focal  point  for  the  unified 
and  specified  CINCs  to  inject 

requirements  into  the  planning  process, 
and  a  voice  in  the  Planning, 

Programming  and  Budgeting  System.  The 
involvement  would  continue  throughout 
the  acquisition  as  the  command  assisted 

the  executive  agent  in  balancing 

technical  considerations  with  such 
operational  factors  as  survivability 
enhancements,  replenishment  philosophy, 
position  management  and  operational 
concepts.  Finally,  exercises  in  joint 
operations  would  be  coordinated  through 
the  SPADOC. 

This  final  action,  coordination  of 
joint  exercises,  is  one  area  where 
SPADOC  and  OM  of  MILSATCOM  systems  can 
and  should  begin  to  work  together  now. 
The  experience  with  space  systems  in 
exercises  is  limited,  and  noted  most 
for  pointing  out  areas  where 
improvement  is  needed.  Although  no  OM 
likes  to  think  about  intentionally 
denying  service,  and  no  user  wants  to 
see  his  support  disrupted,  it  is 
essential  that  operators  practice  how 
they  would  respond  to  increased  demands 
or  loss  of  capability  — even  to  the 
extent  of  moving  users  from  one  system 
to  another.  The  key  to  a  good  crisis 
response  is  knowing  beforehand  what 
must  be  done  and  how  to  do  it.  The 
knowledge  can  only  come  through  good 
planning  followed  by  test  and  exercise. 

In  order  for  SPADOC  to  take  on  a 
role  in  MILSATCOM  coordination  two 
things  must  occur.  First,  the  SPADOC 
must  have  people  who  understand  the 
operational  missions  of  the  warfighters 
and  the  capabilities  of  the  SATCOM 
systems.  Services  must  be  willing  to 
assign  good  people  to  staff  and  crew 
positions  in  Space  Command.  Second,  the 
SPACECOM  staff  and  the  Operational 
Managers  must  work  very  closely  to 
define  the  proper  division  of 
responsibility.  It  would  be  very  easy 
for  SPADOC  to  take  on  a  job  it  could 
not  perform.  The  OM  are  the  experts  in 
the  systems  and  can  best  determine  how 
SPADOC  can  assist  them  in  performing 
their  missions. 

*  *  * 

The  views  contained  herein  are  those  of 
the  author.  Sponsorship  of  this  research 
by  the  Center  for  Advanced  Research,  Naval 
War  College,  does  not  constitute  approval 
thereof  by  the  Naval  War  College,  the 
Department  of  the  Navy,  or  any  other 
branch  of  the  United  States  government. 
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The  Command  Post  Modem/Processor  (CPM/P)  Ad¬ 
vanced  Development  Program  makes  extensive  use  of 
micro-computer  technology  in  the  design  of  a 
subsystem  of  an  Airborne  Satellite  Communications 
(SATCOM)  system.  This  SATCOM  system  is  being  de¬ 
signed  for  eventual  application  on  the  Airborne 
Command  Post  fleet  of  aircraft  to  provide  command 
of  functions  including  message  handling  (routing), 
satellite  command  and  control,  satellite  ranging 
and  pointing  • imputations ,  and  complex  signal  pro¬ 
cessing  while  achieving  a  significant  reduction  in 
size,  weight,  power  consumption,  and  volume  as 
compared  to  present  technologies.  In  addition, 
maintainability,  reliability,  life-cycle  cost,  and 
self-test  are  significant  objectives  in  the  devel¬ 
opment  effort.  The  three  principal  units  of  the 
CPM/P  are  the  Red  Processor,  the  Black  Processor, 
and  the  Modem,  each  housed  in  1/2-ATR  long  LRU  and 
each  containing  two  micro-computers.  The  CPM/P 
and  the  associated  receiver/transmitters  are  con¬ 
trolled  through  the  use  of  a  plasma  display,  an 
interactive  display  which  is  designed  to  aid  the 
operator  in  decision  making  and  thus  reduce 
demands  on  the  operator  during  system  operation- 


introduction 


The  Command  Post  Modem/Processor  (CPM/P)  Ad¬ 
vanced  Development  Program  was  initiated  by  the 
Avionics  Laboratory  of  the  Air  Force  Wright  Aero¬ 
nautical  Laboratories  in  March  1978  under  Contract 
F33615-77-C-1269  with  the  Linkabit  Corporation  of 
San  Diego,  California.  The  general  program  objec¬ 
tive  was  the  development  of  Military  Satellite 
Communications  (MILSATCOM)  technologies  in  support 
of  Airborne  Command  Post  terminal  segment  develop¬ 
ment  for  existing  and  planned  satellite  communica¬ 
tions  systems.  The  CPM/P  is  the  modem/processor 
subsystem  of  a  comprehensive  Satellite  Communica¬ 
tions  (SATCOM)  terminal.  The  CPM/P  is  designed  to 
Interface  with  associated  UHF/SHF/EHF  Receiver/ 
Transmitter  (R/T)  terminal  subsystems  and  other 
onboard  equipments  to  provide  the  Integration 
function  within  the  SATCOM  terminal.  Through  the 
use  of  micro-computer  technology  and  extensive 
digital  implementation,  the  CPM/P  provides  a 
multiplicity  of  communications,  command,  and  con¬ 
trol  capabilities  while  achieving  a  significant 
reduction  in  size,  weight  and  power  consumption  as 
compared  to  existing  technological  capabilities. 
Operating  as  a  part  of  the  SATCOM  terminal  the 


CPM/P  provides  for  emergency  action  message  (EAM) 
dissemination  and  communications  among  the  Nation¬ 
al  Command  Authorities,  the  Joint  Chiefs  of  Staff, 
the  Commanders -in-Chief ,  and  the  strategic  force 
elements  consisting  primarily  of  bombers  and 
missle  launch  control  centers.  The  CPM/P  design 
includes  the  capability  to  configure/control/ 
monitor  the  SATCOM  terminal  R/T  subsystems;  to 
initiate  command  functions  for  satellite  control; 
and  to  establish  and  control  communications 
networks.  The  SATCOM  terminal,  including  the 
CPM/P,  is  designed  to  operate  with  a  variety  of 
satellites  in  geosynchronous  and  inclined  orbits 
and  in  the  UHF,  SHF,  and  EHF  frequency  spectrums. 

The  SATCOM  terminal  is  comprised  of  a  variety 
of  equipments  from  a  variety  of  sources.  The  UHF 
R/T  group  equipments  and  some  of  the  Input/Output 
(I/O)  group  equipments  are  presently  in  use  in  a 
UHF  SATCOM  terminal  on  the  Airborne  Command  Post 
to  Provide  UHF  AFSATCOM  I  Satellite  Communica¬ 
tions.  The  SHF/ EHF  capability  within  the  terminal 
is  provided  by  the  Small  EHF/ SHF  Airborne  SATCOM 
Terminal  (SESAST)l.  The  SESAST  was  developed 
under  a  parallel  advanced  development  program 
within  the  Avionics  Laboratory.  A  feature  of  the 
SESAST  design  provides  for  either  autonomous  oper¬ 
ation  or  integrated  operation  with  the  CPM/P. 

When  operating  with  the  CPM/P  total  control  of 
terminal  operation  is  achieved  through  that  CPM/P 
Including  SESAST  initialization,  configuration, 
and  monitor. 

CPM/P  General  Description 

The  principal  components  of  the  CPM/P  develop¬ 
ment  effort  are  the  Modem,  the  Black  Processor, 
and  the  Red  Processor.  Two  Modems  along  with  the 
Black  and  Red  Processors  make  up  the  CPM/P.  These 
four  units  are  shown  in  Figure  1.  Each  unit  is 
packaged  in  a  1/2  ATR-Long  chassis.  Figure  2  is  a 
diagram  of  the  SATCOM  Terminal  with  photographs  of 
the  major  CPM/P  components.  The  primary  function 
of  the  Modem,  called  the  Command  Post  Modem  (CPM), 
is  to  transform  baseband  digital  information  into 
the  appropriate  uplink  I-F  waveform  structure  and, 
conversely,  to  transform  received  downlink  I-F 
waveforms  to  baseband  for  further  processing  with¬ 
in  the  CPM/P.  The  Black  Processor  controls  the 
routing  of  data  between  the  Red  Processor  and  the 
CPMs,  controls  the  UHF  Radio  subgroup,  and 
computes  satellite  range/range  rate  and  antenna 
pointing  information.  The  Red  Processor  provides 
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the  system  control  functions  and  the  interface 
with  the  I/O  group. 

Three  other  smaller  units,  the  R/T  Interface, 
the  Reference  Distribution,  and  the  Relay  Control, 
were  developed  as  a  part  of  the  CPM/P  and  perform 
interface  functions.  The  functions  currently  per¬ 
formed  in  these  smaller  units  would  probably  be 
Integrated  into  the  major  Line  Replaceable  Units 
(LRUs)  in  the  next  stage  of  development. 

Maintainability,  reliability  and  life-cycle 
cost  were  considerations  in  the  CPM/P  development 
effort.  To  this  end  the  CPM/P  is  designed  with 
numerous  common  modules,  including  one  power  sup¬ 
ply  which  is  common  to  the  three  major  LRUs.  The 
chassis  for  the  Red  Processor  and  the  Black  Proc¬ 
essor  are  also  interchangeable.  Significant 
reductions  in  size,  weight,  and  power  consumption 
also  contribute  to  improved  reliability,  main¬ 
tainability,  and  life-cycle  cost.  The  CPM/P  also 
includes  a  limited  built-in-test  capability. 

CPM/P  Architecture 

The  primary  development  objective  of  the  CPM/P 
program  of  substantially  reducing  physical  size 
(volume),  weight,  and  power  consumption  while  in¬ 
creasing  functional  capability,  were  achieved 
through  the  use  of  state-of-the-art  micro-computer 
technology  and  the  use  of  extensive  digital 
implementation.  The  basis  of  the  CPM/P  architec¬ 
ture  was  a  result  of  the  works  of  Gllhousen^  and 
Jacobs^.  The  micro-computer  described  by 
Cllhousen  and  Jacobs  was  designed  for  use  in  the 
processing  of  complex  signal  waveforms,  sometimes 
called  the  Llnkablt  Microprocessor  or  LMP. 

A  block  diagram  of  the  LMP  is  shown  in  Figure 
3.  This  block  diagram  of  the  LMP  architecture  is 
from  a  software  polnt-of-view.  The  major  charac¬ 
teristics  of  the  LMP  are  as  follows: 

—  The  average  instruction  execution  rate  of 
the  LMP  is  3  million  Instructions  per 
second ; 

—  The  LMP  is  composed  of  standard  integrated 
circuits; 

—  Its  instruction  set  consists  of  29 
instructions ; 

—  The  LMP  does  not  include  Interrupt  capabili¬ 
ty  but  relies  on  testing  of  external  flags; 
and 

—  It  contains  a  hardware  monitor  for 

overflow/underflow  and  illegal  operation 
codes  or  code  boundaries. 

Within  the  CPM/P  the  hardware  implementation  of 
the  LMP  - s  partitioned  into  either  a  three  or  four 
card  set  consisting  of  a  Processor  Arithmetic 
Card,  a  Processor  Control  Card,  and  either  one  or 
two  Processor  Memory  Cards.  Each  major  LRU  con¬ 
tains  two  IMPs.  The  card  layout  for  the  Command 
Post  Modem  is  shown  in  Figure  4.  The  Processor 
Arithmetic  Cards  (A12)  are  interchangeable  as  are 
the  Processor  Control  Cards  (A13).  The  program  is 


stored  in  ROM  on  the  Processor  Memory  Cards.  The 
LMP  can  address  up  to  64  pages  of  ROM,  with  a  page 
consisting  of  4096  instructions  and  each  instruc¬ 
tion  5  bits  in  length.  Each  Processor  Memory  Card 
can  contain  up  to  15  pages  of  ROM  or  a  total  of  30 
pages  per  LMP  using  16K  ROM  devices.  The  Proces¬ 
sor  Memory  Cards  are  designed  to  accommodate  32K 
ROMs  which  will  allow  expansion  to  60  pages  per 
LMP.  Using  the  16K  ROMs  the  CPM/P  is  presently  at 
approximately  84%  of  capacity. 

SATCOM  Terminal 

The  function  of  the  CPM/P  is  best  illustrated 
when  described  as  an  operating  part  of  the  multi¬ 
functional  airborne  SATCOM  terminal  shown  in 
Figure  2.  A  number  of  advanced  development  tech¬ 
nologies  provided  in  this  terminal  can  be 
transitioned  to  the  operational  fleet  to  meet  the 
Airborne  Command  Post  requirements  for  existing 
and  planned  MILSATCOM  systems. 

The  Input/Output  (I/O)  group  consists  of  two 
plasma  displays,  two  Automatic  Send-Receive  (ASR) 
devices,  a  high  speed  printer,  and  a  magnetic  tape 
cassette  unit.  The  two  plasma  displays  provide 
for  centralized  control  of  terminal  operations  and 
configurations,  with  the  ASRs  supplying  backup. 

The  operation  of  the  plasma  displays  are  comple¬ 
mentary,  l.e.  the  two  units  would  not  be  used  on 
the  same  job  at  the  same  time.  The  high  speed 
printer  is  used  to  log  all  communications  traffic 
and  selected  status/control  Information.  The 
function  of  the  cassette  unit  is  to  load  the  sys¬ 
tem  data  base  and  satellite  ephemeris  data. 

The  Red  Processor  provides  the  interface  with 
the  I/O  group  and  stores  the  operating  data  base. 
The  Black  Processor  serves  as  the  interface  with 
the  Modems  and  computes  satellite  range/range  rate 
and  pointing  information.  The  function  of  the 
Inertial  Navigation  System  (LTN-51)  is  to  furnish 
aircraft  dynamic  data  required  in  the  computation 
of  satellite  range/range  rate  and  pointing 
information.  The  EAM  Alarm  provides  an  audible 
and  visual  indication  of  the  reception  of  an  Emer¬ 
gency  Action  Message. 

The  two  Modems  are  identical  and  perform  all 
the  signal  processing  functions.  They  can  provide 
simultaneous  communications  through  different  sat¬ 
ellite  links  and/or  provide  redundancy  to  improve 
reliability.  The  KI-35s  shown  Interfacing  with 
the  Modems  supply  TRANSEC  compatibility  with  the 
SCT  satellite  communications  links.  The  Modems 
interface  with  the  UHF  R/Ts  and  the  SESAST  at  an 
intermediate-frequency  of  70  MHz  through  the  RF 
switching  matrix.  The  UHF  R/Ts  are  full-duplex 
AN/ARC-171s  presently  used  in  the  operational 
AFSAT  I  Command  Post  terminals.  The  SESAST  pro¬ 
vides  the  SHF/EHF  capability. 

A  detailed  block  diagram  of  the  SATCOM  terminal 
is  shown  in  Figure  5.  The  blocks  accentuated  by 
the  heavy  borders  are  the  equipments  developed  or 
purchased  as  a  part  of  the  CPM/P  development 
effort. 
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Multiple  Satellite  Operation 

The  SATCOM  terminal  is  designed  for  multiple 
satellite  operations  with  a  data  base  of  up  to 
forty  satellites  with  a  variety  of  circular  and 
elliptical  orbits.  The  terminal  can  operate  si¬ 
multaneously  with  either  two  UHF  satellites  or  one 
UHF  and  one  SHF/EHF  satellite.  The  design  pro¬ 
vides  for  pre-correction  in  time  and  frequency  for 
the  uplink  signals  radiated  by  the  aircraft.  This 
pre-correction  compensates  for  relative  Doppler 
and  the  time  delay  between  the  aircraft  and  the 
satellite.  In  addition,  azimuth  and  elevation 
pointing  information  is  computed  within  the  CPM/P 
to  point  the  EHF/SHF  directional  antenna.  This 
pre-correction  in  time  and  frequency  along  with 
the  antenna  pointing  information  allows  for  rapid 
acquisition  of  complex  waveforms,  as  well  as 
"open-loop"  operations  with  satellites  which  have 
no  continuous  communications  or  telemetry 
downlinks. 

To  achieve  efficient  and  accurate  operation 
with  a  forty  satellite  data  base  while  minimizing 
downtime  during  switching  between  satellites,  a 
comprehensive  ephemeris  computational  algorithm  to 
compute  range/range  rate  and  antenna  pointing 
angles  was  developed  and  implemented  in  the 
CPM/P.  The  initial  analysis  and  development  of 
the  ephemeris  computational  algorithm  was  accom¬ 
plished  by  Orincon^.  The  Orincon  effort  was 
followed  by  implementation  in  the  CPM/P  described 
by  Rothmuller  and  Rosenlof^. 

Centralized  Control 

Due  to  the  number  and  variety  of  communications 
assets  which  make-up  and  Interface  with  the  SATCOM 
terminal,  the  control/monitor  function  is  an  im¬ 
portant  design  consideration.  The  primary 
display/control  function  in  the  CPM/P  and  the 
SATCOM  terminal  is  achieved  through  the  use  of  a 
plasma  display.  The  display/control  function  is 
designed  to  require  minimal  operator  interaction 
and  serves  as  an  aid  to  the  operator  in  decision 
making. 

The  method  of  display /control  is  achieved  by 
providing  a  menu  of  choices  to  the  operator 
through  the  use  of  the  plasma  display.  Following 
a  selection,  another  menu  of  choices  is  offered, 
and  so  on,  until  the  system  is  operating  with  a 
given  set  of  conditions.  Terminal  resources  are 
automatically  allocated  and  system  operating 
parameters /levels  are  automatically  set  through 
the  process.  A  typical  menu  set  is  shown  in  Fig¬ 
ure  6.  The  upper  section  of  the  screen  displays 
status  messages  which  are  provided  automatically, 
ranging  from  system  faults  to  the  availability  of 
terminal  assets.  Each  message  is  preceded  by  the 
time  and  date  with  the  most  current  message  on  the 
bottom.  Only  the  four  most  recent  messages  are 
displayed.  Status  messages  are  also  routed  to  the 
high  speed  printer  for  permanent  logging.  The 
lower  section  of  the  screen  displays  the  menu  of 
choices.  Graphics  are  also  used  to  aid  the 
operator. 


The  centralized  control  concept  and  the  design 
of  the  CPM/P  provides  a  limited  implementation  of 
Built-in-Test  (BIT).  Detected  system  faults  are 
automatically  displayed  as  status  messages  (upper 
section  of  the  plasma  display)  including  the  pos¬ 
sible  location  of  the  fault.  The  basis  for  the 
CPM/P  BIT  is  a  result  of  the  BIT  program  imple¬ 
mented  in  the  UHF  Dual  Modern^. 

Summary  of  CPM/P  Principal  Features 


The  principal  features  of  the  CPM/P  when  oper¬ 
ating  as  a  part  of  the  SATCOM  terminal  as  de¬ 
scribed  in  this  paper  can  be  summarized  as 
follows: 

—  Significant  reduction  in  size,  weight,  and 
power  consumption  with  increased  functional 
capability; 

—  Compatible  with  all  communication  modes  of 
both  the  AFSAT  I  and  the  Sing..'1  Channel 
Transponder  (SCT)  Satellite  Communications 
Systems ; 

—  Satellite  Command /Control  and  Monitor 
Capabilities ; 

—  Centralized  Control  over  the  SATCOM 
terminal ; 

—  Multiple  satellite  operation  with  a  forty 
satellite  data  base,  and  range/range  rate 
and  antenna  pointing  computations;  and 

—  A  number  of  advanced  development  technolo¬ 
gies  which  can  be  transitioned  to  the  next 
stage  of  development. 
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ABSTRACT 


This  paper  highlights  a  study  activ¬ 
ity  which  assessed  the  impact  o  £  proposed 
Shuttle  vehicle  improvements  on  the  tasks 
associated  with  Shuttle  Mission  Opera¬ 
tions.  These  tasks  were  divided  into  the 
following  Mission  Operations  phases:  (1) 
Flight  Planning  Phase;  (2)  Flight  Readi¬ 
ness  Phase;  (3)  Flight  Control  Phase. 
Vehicle  improvements  identified  for 
assessment  were:  (1)  Autonomous  navigation; 
(2)  Automated  failure  diagnosis;  (3) 
Increased  crew  size;  (4)  Onboard  consum¬ 
able  analysis;  (5)  Software  Flight  Data 
File;  (6)  Advanced  inflight  maintenance. 
Task  analyses  of  the  Mission  Operations 
phases  provided  the  baseline  criteria  on 
which  to  make  the  impact  assessment  of  the 
improvement  candidates.  Incorporation  of 
vehicle  improvements  which  contribute  to 
autonomous  Shuttle  operations  is  one  of 
the  proposed  solutions  for  reducing  Mission 
Operation  activities  and  staffing. 

INTRODUCTION 

As  the  Shuttle  Transportation 
System  (STS)  advances  into  the  operational 
era  all  Mission  Operations  activities 
should  be  examined  with  the  intent  of 
providing  payload  and  scheduling  flexibil¬ 
ity,  supporting  increasing  flight  rates, 
and  reducing  cost  per  flight.  One  area 
which  is  a  major  contributor  to  current 
STS  cost  is  Mission  Operations.  Mission 
Operations  in  the  context  of  this  study 
are  those  activities  which  must  be  per¬ 
formed  during  the  Flight  Planning  Phase  of 
a  mission,  those  activities  performed  dur¬ 
ing  the  Flight  Readiness  Phase  of  a 
mission,  and  those  activities  performed 
during  the  Flight  Control  Phase  of  a  mis¬ 
sion.  Launch  operations  and  vehicle  turn¬ 
around  activities  were  considered  a  separ¬ 
ate  subject  and  were  not  directly  addressed 
in  this  study. 

Mission  Operations  (By  Phase) 

Flight  Planning  Phase 


o  Flight  Integration 

o  Fight  Design  (System  X  and  System  Y) 
o  Crew  Activity  Planning  (CAPS) 

Flight  Readiness  Phase 

o  Training  and  Simulation 
o  Flight  Software  Preparation 
o  Ground  Systems  (MCC  H/W  &  S/W) 

Flight  Control  Phase 

o  Procedures  Development 

o  Flight  Operations  Support  Personnel  (FOSP) 
o  Flight  Crews 

Numerous  Shuttle  vehicle  improve¬ 
ments  have  been  proposed  and  evaluated  on 
the  basis  of  performance,  safety,  turn¬ 
around  time  reduction,  and  cost.  One  area 
which  has  been  identified  as  having  the 
potential  of  reducing  Mission  Operations, 
is  the  implementation  of  vehicle  improve¬ 
ments  with  autonomous  vehicle  thrust.  It 
was  the  intent  of  this  study  to  evaluate 
selected  autonomous  vehicle  improvement 
candidates  for  impact  in  the  Mission  Opera¬ 
tions  area  of  Flight  Planning,  Flight 
Readiness  and  Flight  Control. 

It  was  anticipated  that  the  impact 
of  the  vehicle  improvement  candidates  will 
reduce  Mission  Operations  in  many  respects. 
However,  it  was  also  anticipated  that  there 
would  be  displacements  of  activities  as 
well  as  increases  in  activities  associated 
with  improvement  candidate  implementation. 
This  aspect  of  proposed  improvements  has 
seldom  been  addressed  in  the  traditional 
evaluation  studies  performed  for  NASA  pro¬ 
grams  . 

APPROACH 

The  basic  approach  used  for  this 
study  is  illustrated  in  Figure  1.  The 
initial  investigation  focused  on  identify¬ 
ing  vehicle  improvement  candidates  which 
provide  or  contribute  to  autonomous 
vehicle  operations.  Reviews  of  existing 
studies  and  related  documentation  were 
performed  and  a  group  of  potential  candi¬ 
dates  were  identified.  From  this  prelimin¬ 
ary  group,  the  most  influential  six  candi¬ 
date  improvements  were  selected  and  des- 
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cribed  for  subsequent  utilization  in  this 
study. 

The  next  step  in  the  study  approach 
was  the  development  of  task  analyses  for 
the  respective  Mission  Operations  activ¬ 
ities.  Each  of  the  Mission  Operations 
phases  (Flight  Planning,  Flight  Readiness, 
and  Flight  Control)  was  further  divided 
into  the  specific  areas  of  support  and 
the  tasks  within  each  support  activity 
were  identified. 


FIGURE  1  -  STUDY  APPROACH 

The  third  step  in  the  study  approach 
called  for  t^a  impact  assessment  of  the 
candidate  veuicle  improvements  upon  the 
individual  Mission  Operations  task  analy¬ 
ses.  By  utilizing  the  candidate  vehicle 
improvement  descriptions  and  identified 
capabilities,  the  impact  on  the  Mission 
Operations  task  analyses  were  identified. 

The  assessment  data  was  subsequently 
utilized  to  compile  the  overall  impact 
evaluation  and  summary. 

Improvement  Candidate  Descriptions 

The  following  paragraphs  provide  a 
summary  description  of  the  autonomous 
vehicle  improvement  candidates. 

Autonomous  Navigation  -  Autonomous 
Navigation  in  the  conceptual  form  being 
studied  in  the  literature  utilizes  an 
Orbiter  onboard  navigator  in  conjunction 
with  the  Global  Positioning  System  (GPS) 
to  obtain  independent  Orbiter  navigation 


updates  (3).  This  concept  negates  the 
requirement  for  externally  generated  up¬ 
dates  to  the  navigator  from  dedicated 
tracking  and  data  processing  facilities 
on  the  ground. 

Automated  Failure  Diagnosis  - 
Automated  Failure  Diagnosis  capability 
for  the  Orbiter  will  be  implemented  as 
applications  to  the  onboard  software  pro¬ 
gram.  Upon  activation  by  an  out-of-toler¬ 
ance  condition  the  program  would  cycle  to 
diagnose  the  problem.  Upon  completion  of 
the  diagnosis,  the  failure  solution  will 
appear  on  the  onboard  CRT  along  with  appro¬ 
priate  corrective  action  instructions  to 
the  crew.  The  automated  failure  diagnosis 
applications  will  apply  primarily  to  non¬ 
software  driven  systems. 

Increased  Crew  Size  -  An  increase 
in  size  to  four  or  more  members  will  occur 
on  operational  Shuttle  flights.  This  will 
allow  the  Orbiter  to  be  operated  on  a 
"shift"  basis  which  permits  continuous 
flight  activities.  The  crew  will  be 
available  for  full  time  monitoring  of  the 
Orbiter  and  for  the  performance  of  off- 
nominal  procedures  if  required.  The 
Spacelab  mission  will  provide  the  initial 
occurence  of  "shift"  operations  onboard 
the  Shuttle. 

Onboard  Consumable  Analysis  -  Onboard 
consumable  analysis  is  also  a  flight  soft¬ 
ware  program  application.  This  program 
will  give  the  flight  crew  the  capability 
to  evaluate  all  onboard  consumables  and 
provide  projections  of  supply  for  various 
vehicle  conditions.  The  crew  would  have 
the  capability  to  evaluate  contingency 
deorbit  cases  independent  of  ground  track¬ 
ing  and  data  processing  facilities. 

Software  Flight  Data  File  -  Placing 
certain  volumes  of  the  Flight  Data  File 
in  the  mass  memory  of  the  onboard  soft¬ 
ware  load  will  result  in  a  weight  reduc¬ 
tion  for  the  Orbiter.  This  concept  would 
apply  to  flight  documents  that  are  util¬ 
ized  during  the  on-orbit  phase  of  the 
mission.  This  concept  would  also  provide 
a  hard-copy  capability  on  the  Orbiter  to 
reduce  CRT  display  burden. 

Advanced  Inflight  Maintenance  - 
Advanced  Inflight  Maintenance  (IFM)  will 
increase  the  probability  of  mission  suc¬ 
cess  by  providing  the  Orbiter  crew  with 
the  capability  to  effect  onboard  repairs. 

In  the  advanced  concept  these  repairs  are 
envisioned  to  be  accomplished  on  payloads 
(Orbiter  IFM  will  be  standard  practice) . 
Equipment,  spare  parts,  and  procedures 
would  be  stowed  onboard  the  Orbiter  as  an 
"optional  service”.  The  planning  and 
training  for  this  capability  would  also  be 
provided  as  part  of  the  "optional  service". 
Payloads  having  national  priority  or  pay- 
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loads  representing  new  technology  and  un-  Tables  1,  2  and  3  for  Flight  Planning, 

proven  reliability  would  be  candidates  for  Flight  Readiness,  and  Flight  Control 

the  advanced  inflight  maintenance  service.  activities  respectively. 

MISSION  OPERATIONS  TASK  ANALYSIS  IMPROVEMENT  CANDIDATE  IMPACT 

DEVELOPMENT  ASSESSMENT 

The  development  of  the  Mission  Oper-  During  this  phase  of  the  study  task 

ations  task  analyses  was  accomplished  by  each  of  the  candidate  improvement  ;  was 

utilization  of  NASA  JSC  documentation,  evaluated  for  impact  to  the  Mission  Oper- 

NASA  interviews  with  incumbent  NASA  JSC  ations  phase  and  functional  activities, 

and  contractor  personnel  (6),  (7),  (8).  The  evaluation  first  addressed  whether  or 

The  tasks  identified  are  presented  in  not  there  was  impact  to  the  functional 
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TABLE  1  -  FLIGHT  PLANNING  TASK  ANALYSIS 


TRAINING  AND  SIMULATION 


FLIGHT  SOFTWARE 


(MCC  H/W,  S/W) 


Perfora  Training  Requlreaents 
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Develop  Training  Plans  and 
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Davalop  Training  Flows 
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TABLE  2  -  FLIGHT  READINESS  TASK  ANALYSIS 


PROCEDURES 
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TABLE  3  -  FLIGHT  CONTROL  TASK  ANALYSIS 


activities  as  identified  in  the  specific 
task  analysis.  When  an  impact  condition 
was  identified  an  assessment  was  made  to 
determine  if  the  condition  was  encounter¬ 
ed  on  the  initial  mission  only  or  would 
cause  recurring  impact  on  all  subsequent 
missions.  The  final  determination  to  be 
made  dealt  with  the  workload  influence 
of  the  impact.  Factors  were  evaluated  to 
identify  a  positive  (+)  or  negative  (-) 
workload  index  for  each  impact  condition. 
In  certain  instances  impacts  were  identi¬ 
fied  but  the  workload  index  remained  un¬ 


determined  because  the  workload  increase 
and  decrease  caused  by  the  improvement 
would  approximately  cancel  out. 

IMPROVEMENT  IMPACT  SUMMARY  MATRIX 

Table  4  reflects  the  Improvement 
Impact  Summary  Matrix.  This  table  indie 
ates  that  providing  the  flight  crew  with 
autonomous  vehicle  capabilities  will 
cause  workload  increases  in  most  of  the 
Mission  Operations  categories.  The  most 
significant  workload  increase  is  on  the 
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flight  crews  expected.  However,  the  in¬ 
creased  workload  in  simulation  and  train¬ 
ing  appears  equally  substantial  and  may 
cause  an  increased  need  for  training 
facilities  and  resources.  The  most  signi¬ 
ficant  reduction  in  workload  will  occur  in 
the  area  of  flight  operations  support. 

It  was  beyond  the  scope  of  this  study  to 
further  develop  the  impact  assessment  in 
quantifiable  terms  (i.e.,  man  hours). 

The  natural  progression  for  the  study  would 
be  the  development  of  a  mathematical  model 
in  which  the  mission  complexity  (high, 
medium,  low) ,  the  mission  duration,  and 
the  crew  size  would  be  variables  to  be 
initialized  for  evaluation  of  a  parti¬ 
cular  improvement  candidate.  This  would 
then  permit  a  summation  of  the  impact 
across  the  mission  phases  and  provide  a 
quantified  answer  for  staffing  or  cost 
estimate  purposes.  An  additional  para¬ 
meter  would  be  the  estimate  of  pay-back 
potential  of  implementing  a  particular 
improvement  candidate  across  a  specific 
number  of  missions. 
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INTEROPERABILITY  OF  SPACE  COtWNlCATIONS  SYSTEMS 


COL  ROBERT  H.  GIBSON 
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We  define  interoperability  as  the  ability  of  networks  to  interchange 
links,  space  nodes  or  ground  nodes.  This  concept  requires  three  ingredients 
for  implementation.  The  first  part  is  functional  satellite  and  ground  data 
link  standards  for  mission  data;  communications;  and  tracking,  telemetry  and 
command  (TT&C).  All  links  use  a  common  transmission  format  so  diverse 
hardware  from  a  variety  of  systems  can  interoperate.  The  second  component  is 
an  architecture  that  defines  the  systems,  links,  and  facilities  (the  nodes) 
which  will  be  internetted.  The  last  ingredient  is  the  operations  concept 
which  provides  the  organization,  procedures  and  protocols  that  allow  inter¬ 
operability. 

This  paper  outlines  and  examines  all  three  areas.  It  describes  the 
problems  and  compromises  required  to  produce  a  useful  satellite  data  link 
standard  and  presents  interoperability  scenarios  that  illustrate  alternate 
routes  and  how  they  can  be  used. 
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ABSTRACT 


■J 

For  the  past  25  years  the  Department  of  Defense  (DoD)  has  become 
increasingly  involved  in  the  use  of  satellites  for  communications,  navigation, 
surveillance  and  other  missions.  The  support  of  these  space  missions 
required  a  growing  number  of  ground  systems  which  were  developed 
essentially  independent  of  each  other.  The  advent  of  the  Space  Transporta¬ 
tion  System^ STS)  as  a  reusable  launch  vehicle  and  the  upgrade  of  several 
existing  command  and  control  centers  have  provided  the  opportunity  to 
pursue  commonality  in  the  development  or  upgrade  of  these  centers.  The 
potential  commonality  included  software,  hardware,  procedures,  training 
and  operational  concepts.  Further  investigation  revealed  excellent  com¬ 
monality  in  high  level  software  and  data  processing^ stems.  The  advent  of 
the  Consolidated  Space  Operations  Center  (CSOC)  which  comprises  seven 
segments  and  some  co  located  program  elements  provided  even  more 
impetus  for  a  commonality  approach  to  DoD  command  and  control 
centers. 

The  programs  specifically^ addressed  included  the  Shuttle  Operations 
and  Planning  Complex  (SOPC) ,  System  Modernization  (DSM); 

the  Global  Positioning  SystemtGPS)  and  the  Johnson  Space  Center  (a 
National  Aeronautics  and  Space  Aministration  facility).  The  commonality 
results  achieved  to  date  and  the  ongoing  investigation  will  be  presented  in 
the  paper. 
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INTRODUCTION 


The  Department  of  Defense  (DoD)  and  the  National  Aeronautics  and 
Space  Administration  (NASA)  utilization  of  the  Space  Transportation  Sys¬ 
tem  (STS)  and  other  satellites  requires  ground  control  centers.  Each  con¬ 
trol  center  must  provide  certain  capabilities  and  perform  certain  functions 
that  are,  to  a  large  degree,  common  to  the  other  control  centers. 

Several  factors  such  as  outdated  equipment,  increased  data  rates, 
saturated  data  systems,  high  life  cycle  costs  and  single  nodes  of  failure 
prompted  the  upgrade  or  building  of  a  number  of  control  centers.  Those 
under  DoD  include: 

•  The  Air  Force  Satellite  Control  Facility  (AFSCF)  is  the  cur¬ 
rent  DoD  facility  for  controlling  and  monitoring  military 
satellites.  The  Data  System  Modernization  (DSM)  is  the 
upgrade  to  the  command  and  control  segment  at  the  SCF  and 
is  in  development. 

•  The  NAVSTAR  Operations  Center  houses  the  Master  Control 
Station  (MCS)  for  overall  control  of  the  Global  Positioning 
System  (GPS)  and  is  currently  under  development. 

•  The  Shuttle  Operations  and  Planning  Complex  (SOPC)  will  be 
the  DoD  facility  for  planning  and  controlling  military  Shuttle 
minions. 

•  The  Space  Defense  Operations  Center  (SPADOC)  provides  cen¬ 
tralized  communications  and  command  for  defense  purposes. 


e  The  Satellite  Operations  Complex  (SOC)  is  a  planned  backup 
and  loadsharing  replication  of  DSM. 

•  The  Consolidated  Space  Operations  Center  (CSOC)  is  scheduled 
to  provide  a  centralized  facility  for  military  space  operations. 
It  will  house  SOPC,  SOC,  MCS  and  other  military  programs. 

•  Vandenberg  Air  Force  Base  (VAFB)  provides  launch  facilities 
for  the  Western  Test  Range. 

Mission  Control  Centers  under  NASA  include: 

•  The  Johnson  Space  Center  (JSC)  where  NASA  plans  and 
controls  civilian  space  missions  and  provides  an  early  DoD 
Shuttle  capability  prior  to  SOPC  activation. 

•  The  Kennedy  Space  Center  (KSC)  provides  Eastern  Test  Range 
launch  facilities  for  NASA  and  DoD. 

•  The  Goddard  Space  Flight  Center  (GSFC)  which  provides  net¬ 
work  control  for  NASA. 


Thus,  the  situation  exists  whereby  DoD  and  NASA  are  upgrading  or 
planning  to  build  several  control  centers  which  appear  to  have  a  large  set 
of  common  requirements.  The  problem  is  to  determine  the  best  means  of 
providing  that  common  set  of  capabilities  in  a  cost-effective  and  timely 
manner.  Furthermore,  the  Zeiberg  TWX1.  the  Office  of  Management  and 
Budget  guidelines  and  Presidential  Directive  37  imposed  specific  require¬ 
ments  and  factors  to  be  considered  in  implementing  the  DoD  control 
centers.  The  more  significant  ones  are  as  follows: 


a.  Interoperability  —  the  requirement  for  one  center  to  perform 
specified  backup  functions  for  another  center; 

b.  Transition  —  the  transitioning  of  flight  operations  from  one 
center  to  another; 

c.  Training  -  the  addition  of  interoperability  and  transition  to 
the  normal  training  requirements; 

d.  Transferability  —  the  recovery  or  transfer  of  large  amounts  of 
existing  software; 

e.  Technology  —  the  upgrading  of  outdated  equipment  and  the 
replacing  of  special  built  equipment  with  commercial  gear  while 
maintaining  interoperability  and  software  transferability;  and 

f.  Configuration  Management  —  the  requirement  to  keep  sepa¬ 
rate  centers  in  some  degree  of  synchronization  to  provide  the 
ability  to  use  common  software  products. 


The  Zeiberg  TWX  was  a  request  from  Dr.  Zeiberg,  Deputy  Undersecre¬ 
tary  of  Defense  for  Strategic  and  Space  Systems,  to  Air  Force  Systems 
Command  for  support  in  investigating  specified  satellite  related  issues. 
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THE  COMMONALITY  APPROACH 


SYSTEM  LEVEL  SOFTWARE 


I  n  the  past,  centers  have  been  developed  essentially  independently,  not 
drawing  upon  each  other's  experience  and  products.  Such  action  has 
resulted  in  some  amount  of  risk,  schedule  and  cost  exposures  that  perhaps 
could  have  been  avoided.  However,  recent  studies  within  FSD  have  shown 
that  it  is  highly  desirable  to  develop  these  control  centers  so  as  to  take 
advantage  of  common  elements  in  both  hardware  and  software  from  one 
center  to  another.  In  addition,  it  is  desirable  to  use  existing,  field-proven 
components  when  possible.  This  commonality  provides  significant  advan¬ 
tages  in  reducing  development  and  life-cycle  costs,  improving  schedules, 
and  perhaps,  most  importantly,  enhancing  reliability  and  thus  reducing 
the  overall  technical  risk  in  developing  highly  complex  realtime  command 
and  control  systems  (Refer  to  Figure  1.) 

The  commonality  approach  embraces  hardware,  software,  training, 
procedures  and  other  aspects  of  command  and  control  centers.  This  paper 
focuses  on  a  commonality  approach  to  software  but  fruitful  efforts  in  the 
other  areas  are  underway. 

Preliminary  work  on  the  feasibility  of  a  commonality  approach  was 
done  by  FSD  at  its  facility  in  Houston  as  part  of  an  effort  to  use  software 
from  the  Shuttle  Ground  Based  Space  System  (GBSS)  in  the  Shuttle  Pay¬ 
load  Operations  Control  Center  (POCC),  each  using  an  IBM  System/370 
Model  168.  These  efforts  were  advanced  in  Gaithersburg  during  the  pro 
rosal  phases  for  both  the  Global  Positioning  System,  a  spacebased  radio 
frequency  navigation  and  positioning  system,  and  the  Data  System 
Modernization  program,  an  upgrade  for  the  SCF.  Results  of  these  efforts 
showed  that  IBM's  303X  and  4300  series  processors  provide  solutions  to 
hardware  requirements,  while  significant  amounts  of  existing  software 
produced  by  other  IBM  divisions  and  FSD  offer  a  large  common  software 
foundation  for  realtime  command  and  contro.  system  applications  (1). 


Figure  l. 


RISK  MINIMIZATION 

-  Utilization  Of  Proven  Hardware  and  Software 
Improves  Development  Schedules 

-  Early  Availability  Of  Experienced  Personnel 


REDUCED  LIFE  CYCLE  COST 

-  Common  Hardware  And  Software  Baselines 
Minimize  Development  Costs 

-  Common  Facilities  For  Software  Development 

-  Common  Maintenance  Procedures  For  Hard¬ 
ware/Software 

-  Reduced  Person nel/T raining  Costs 


OTHER  CONSIDERATIONS 

—  Interoperability 

—  Reliability 

—  Flexibility 

—  Growth 


The  advantages  of  commonality  are  present  in  the 
acquisition,  activation  and  operational  phases. 


The  common  software  concept  is  shown  in  Figure  2.  The  nucleus  of 
the  diagram  contains  the  software  (over  five  million  source  lines)  which  is 
common  to  GBSS,  DSM,  and  the  GPS  Master  Control  Station.  This  includes 
existing  IBM  products:  the  Multiple  Virtual  Storage  (MVS)  operating  sys¬ 
tem,  the  Time  Sharing  Option  (TSO),  the  System  Productivity  Facility 
(SPF)  and  the  Virtual  Telecommunications  Access  Method  (VTAM).  Also 
included  in  this  common  nucleus  is  existing  software  developed  by  FSD  for 
the  Shuttle  Ground  Based  System:  the  Program  Management  Facility 
(PMF),  a  library  management  system  used  to  control  software  during  its 
development:  and  the  Advanced  Statistics  Collector  (ASC),  a  performance 
measurement  tool  used  to  fine-tune  the  realtime  system. 

Extending  this  nucleus  of  common  software  is  the  realtime  executive 
(RTX),  another  GBSS-based  product  which  adds  to  the  standard  MVS 
operating  system  those  features  required  for  a  real-time  processing  environ¬ 
ment.  Still  another  layer  of  commonality  is  represented  by  FSD  software 
capabilities  in  display  management,  data  base  management  and  test  driver/ 
scenario  generation.  The  final  layer  of  software  commonality  is  represented 
by  kernels  of  software  in  the  applications  which  are  typical  of  space 
oriented  realtime  command  and  control  systems-telemetry,  trajectory, 
command  and  control. 


SYSTEM  SOFTWARE 


FEDERAL  SYSTEMS  DIVISION 

-  Program  Management  Facility 

-  Advanced  Statistics  Collector 

OTHER  IBM  DIVISIONS 

-  Multiple  Virtual  Storage  Operating 
System 

-  Time  Sharing  Option 

-  System  Productivity  Facility 


APPLICATION  EXECUTIVE 


APPLICATION  SERVICES 

•  DISPLAY  MANAGEMENT 

•  DATA  BASE  MANAGEMENT 

•  TEST  DRIVER/SCENARIO  GENERATION 


APPLICATION  KERNELS 

•  TELEMETRY 

•  TRAJECTORY 

•  COMMAND 

•  CONTROL 


Figure  2.  The  common  software  concept  starts  with  a  nucleus 
of  vendor  provided  ( commercial )  operating  system 
and  program  products,  extends  to  a  realtime  applica¬ 
tion  executive,  includes  application  services  and, 
finally,  encompasses  the  application  kernels.  This 
concept  provides  software  packages  that  can  be  used 
on  multiple  projects. 
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THE  APPLICATION  EXECUTIVE 


COMMONALITY  DEMONSTRATIONS 


The  commonality  approach  to  software  is  based  upon  the  concept  of 
the  realtime  application  executive  (RTX).  RTX  provides  several  advantages 
that  are  key  to  commonality  and  transportability.  They  are: 

-  It  provides  die  extensions  to  the  commercial  operating  system 
that  are  necessary  to  meet  realtime  processing  requirements 
such  as  high  data  rates,  extended  support  periods,  special 
error  recovery  procedures  and  system  restart/failover. 

-  It  provides  alternate  means  of  performing  operating  system 
functions  when  those  provided  by  the  commercial  system  can¬ 
not  meet  the  stringent  realtime  performs.  x  requirements. 
Storage,  resource  and  work  management  are  typical  examples. 

-  It  helps  to  insulate  the  applications  from  the  hardware  con¬ 
figuration  by  providing  hardware  support  and  external  data 
interfaces. 

The  significance  of  RTX  is  that  it  allows  the  use  of  unmodified  com¬ 
mercial  operating  systems  and  helps  the  applications  to  be  hardware  con¬ 
figuration  independent  (Figure  3).  When  modifications  to  the  software  are 
necessary  due  to  configuration  changes,  they  can  usually  be  made  in  RTX 
rather  than  in  the  operating  system  or  applications.  Since  RTX  is  about 
150  thousand  source  lines  of  code  versus  several  million  each  for  the  oper¬ 
ating  system  and  applications,  the  benefits  of  this  approach  are  apparent. 


•  OPERATING  SYSTEM 

—  Initialization/Termination 
—  Dynamic  Resource  Allocation 
—  Telecommunications/External  Interfaces 
—  Data  Management  Services 

-  Access  Methods 

-  Utilities 


•  APPLICATION  EXECUTIVE 

—  Realtime  Initialization/Termination 
—  Work  Management 

—  Time  Management 

-  Buffer  Management 

—  Data  Array  Management 
—  Lock  Management 

-  Status  Reporting 

—  Common  Input/Output  Services 
—  Display  Management 

-  Time  And  Data  Routing 
—  Error  Recovery 

-  Logging 

-  Checkpoint/Restart/Switchover 


•  APPLICATIONS 

—  Telemetry  Processing 

—  Command  Processing 

—  Network  Control 
—  Trajectory 

-  Systems  Simulation 

-  Performance  Analysis 


figure  3.  The  distribution  of  system  control  functions  shows 
how  the  application  executive  provides  realtime 
extensions  to  the  operating  system  and  Insulates  the 
applications  from  the  hardware  configuration. 


The  feasibility  of  a  commonality  approach  to  realtime  command 
and  control  systems  software  was  demonstrated  in  three  related  activities 
which  used  the  Ground  Based  Shuttle  System  as  a  base.  In  February  1980, 
the  GBSS  programs,  (over  1,600,000  source  lines)  were  transported  from 
NASA's  mission  control  center  in  Houston  (where  they  were  developed  by 
FSD  and  executed  on  IBM  System/370  Model  168  processors)  to  the  IBM 
facility  at  Gaithersburg,  Maryland.  Only  minor  modifications  to  the 
display  hardware  interfaces  were  required  in  order  to  successfully  execute 
these  large,  complex,  realtime  programs  in  both  IBM  3033  and  4341  pro¬ 
cessors  under  a  standard  MVS  operating  system,  thereby  demonstrating 
the  upward  and  downward  compatibility  of  the  system.  These  programs 
were  used  in  Gaithersburg  as  a  base  for  the  GPS  benchmark  in  March 
1980;  for  the  SOPC  upward  compatibility  demonstration  in  April  1980; 
and  for  the  DSM  Stage  1  demonstration,  in  November  1980.  All  of  these 
efforts  were  highly  successful. 

As  a  result  of  this  work,  both  GPS  and  DSM  will  be  using  all  soft¬ 
ware  elements  of  the  common  nucleus,  plus  an  enhanced  version  of  the 
realtime  executive  and  new  display  software.  Enroute  to  this  achievement, 
major  difficulties  were  overcome,  including  the  establishment  of  a  com¬ 
mon  programming  language  and  a  common  set  of  programming  standards 
for  both  the  DSM  and  GPS  projects. 


APPLICATION  SOFTWARE 

The  preceding  discussion  focused  on  the  operating  system  and  the 
application  executive.  However,  a  significant  effort  to  find  common  appli¬ 
cation  software  was  also  performed.  While  there  was  some  success,  the 
application  area  has  not  yet  been  as  fruitful  as  the  others. 

The  common  application  software  analysis  addressed  DSM,  GPS  and 
GBSS.  The  GBSS  software  is  the  current  baseline  for  SOPC  so  that  the 
analysis  essentially  addressed  three  programs  (viz.,  DSM,  GPS/MCS  and 
SOPC)  which  are  to  be  co  located  at  CSOC.  While  co-location  is  not  neces¬ 
sary  to  obtain  software  commonality  benefits,  it  does  enhance  them. 

Since  virtually  all  currently  envisionec'  space  command  and  control 
systems  have  requirements  for  command,  telemetry  and  trajectory  appli¬ 
cations,  these  areas  were  chosen  for  analysis. 

Command 


The  command  area  was  broken  into  48  distinct  functions.  The  func¬ 
tions  ranged  from  general  support  software,  such  as  programs  to  accept 
and  format  user  inputs,  to  software  which  is  highly  command-specific, 
such  as  programs  to  generate  data  groups  for  uplinking  to  a  vehicle. 

Of  the  48  functions  examined,  18  were  judged  potentially  common 
across  DSM/GBSS/GPS.  A  total  of  24  functions  were  evaluated  potentially 
common  to  DSM/GPS,  with  six  of  these  being  non  GBSS  functions. 
Results  are  summarized  in  Figure  4. 


Total  number  of  functions  examined  =  48 

Number  common  to  DSM/GBSS/GPS  =  18 

Number  common  to  DSM/GPS,  but  not  to 
GBSS  =  24 

Size  of  DSM/GBSS/GPS  common  functions 
in  thousands  of  source  lines  of  code  =  84 


Figure  4.  The  results  of  the  command  commonality  analysis 
show  that  DSM  and  GPS  have  potential  for  a  common 
source  of  about  50%  of  the  functions. 
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The  telemetry  area  was  analyzed  as  32  separate  functions  which 
included  such  areas  as  initialization,  data  stream  processing,  manual  inputs 
processing  and  delogging.  Nineteen  of  the  functions  were  judged  potentially 
common  to  DSM/GBSS/GPS.  No  functions  were  determined  to  be  com¬ 
mon  to  DSM/GPS  exclusive  of  GBSS.  Summary  results  are  shown  in 
Figure  5. 


Total  number  of  functions  examined  =  32 

Number  common  to  DSM/GBSS/GPS  =  18 

Number  common  to  DSM/GPS  but  not 

GBSS  =  0 

Size  of  DSM/GBSS/GPS  common  functions 
in  thousands  of  source  lines  of  code  =  350 


figure  5.  The  results  of  the  telemetry  commonality  study  show 
good  potential  for  common  application  software. 


Trajectory 

The  Trajectory  area  is  unique  among  the  applications  being  considered 
in  this  report  for  two  reasons : 

i)  The  GBSS  trajectory  application  is  vehicle-specific  to  a  larger 
degree  than  are  GBSS  command  and  telemetry ;  that  is.  specific 
Space  Shuttle  characteristics,  such  as  thrust  modeling  for 
engines  specific  to  the  Shuttle,  are  scattered  throughout  the 
GBSS  trajectory  code,  rendering  it  difficult  for  conversion  for 
other  projects'  use. 

ii)  Among  the  three  areas  being  considered,  trajectory  is  the  only 
one  which  is  already  being  implemented,  in  part,  from  a  com¬ 
mon  base  on  the  DSM  and  GPS  projects. 

For  these  reasons,  the  trajectory  analysis  began  not  by  looking  for 
potentially  common  functions  from  the  GBSS  system,  but  rather  by 
looking  at  the  DSM/GPS  "common  base"  referred  to  in  (ii)  above,  namely 
the  Goddard  Trajectory  Determination  System  (GTDS).  GTDS  is  a  highly 
general,  FORTRAN-based,  satellite  tracking  and  orbit  analysis  system 
which  has  been  in  use  at  the  Goddard  Space  Flight  Center  for  several 
years. 

It  provides  many  of  the  functions  needed  for  any  space  tracking  sys¬ 
tem,  such  as  ephemeris  generation  and  differential  correction,  and  offers 
the  user  a  large  amount  of  control  over  the  specific  parameters  which 
govern  the  execution  of  the  function. 

Both  the  generality  of  GTDS  and  the  fact  that  it  has  been  an  oper¬ 
ating  satellite  tracking  system  for  years  make  it  an  attractive  base  for  any 
new  satellite  tracking  application.  For  this  report,  GTDS  was  broken  into 
nine  logical  functions,  ranging  from  functions  of  the  general  support 
nature,  such  as  file  formatting  and  reporting,  to  highly  trajectory-specific 
functions,  such  as  differential  correction.  Six  of  these  functions  were 
evaluated  as  common  to  DSM  and  GPS.  Two  of  the  three  remaining 
functions  exist  in  DSM,  but  not  in  GPS.  A  summary  of  the  results  appears 
in  Figure  6.  where  the  thousands  of  source  lines  of  code  number  repre¬ 
sents  FORTRAN  code. 


An  important  event  for  future  generalized  trajectory  work  was  the 
development  of  the  DSM  Tracking  and  Orbit  Determination  mathematical 
specifications  (21.  This  document,  based  on  GTDS  documents  (3)  which 
served  a  similar  function  for  that  system,  is  sufficiently  thorough  and 
general  to  provide  an  excellent  starting  point  for  creation  of  a  generalized 
trajectory  functional  specification. 

In  addition  to  the  GTDS  functions  surveyed  in  this  report,  there  are 
important  trajectory  functions  for  which  common  development  may  be 
important  and  feasible  for  future  software  systems.  Two  such  functions 
are  attitude  determination  and  maneuver  planning.  No  attempt  has  been 
made  at  this  point  to  assess  their  commonality  potential  in  a  quantitative 
fashion,  but  attention  to  both  functions  is  essential  in  the  development 
of  functional  specifications  for  a  generalized  trajectory  system. 


Total  number  of  GTDS  functions 

=  9 

Number  common  to  DSM/GPS/GTDS 

=  6 

Number  common  to  DSM/GTDS  only 

=  8 

Size  of  DSM/GPS/GTDS  common  func- 

tions  in  thousands  of  source  lines  of  code 

(FORTRAN) 

=  45 

Figure  6.  The  results  of  the  trajectory  commonality  study  indi¬ 
cate  that  the  Goddard  Trajectory  Determination  Sys¬ 
tem  (GTDS)  along  with  the  existing  DSM  system 
(Advanced  Orbital  Ephemeris  System)  would  be  a 
good  choice  as  a  trajectory  base  for  DSM  and  that 
decision  was  made  and  is  being  implemented  on  the 
DSM  contract.  Although  Ground  Based  Space  System 
(GBSS)  trajectory  software  has  a  lot  of  functional 
commonality  with  GTDS.  it  doesn't  appear  in  the 
comparison  because  the  implementation  is  very 
vehicle  specific  and  makes  general  use  difficult. 


OTHER  COMMONALITY  AREAS 


The  preceding  discussion  has  centered  almost  entirely  on  software. 
However,  the  commonality  effort  has  successfully  addressed  several  other 
areas.  Some  of  the  more  significant  are  discussed  below. 

Display  and  Control  Functions 

One  of  the  generic  characteristics  of  a  command  and  control  center 
is  a  display  and  control  system.  This  system  is  used  to  view  incoming  or 
computed  data  and  to  format  and  send  commands.  Typical  equipment 
includes  cathode  ray  tubes,  plasma  displays,  touch  panels,  joy  sticks,  func¬ 
tion  keyboards  and  plotters.  The  display  requirements  seemed  to  hold 
excellent  promise  for  a  common  approach  and  as  a  result  of  a  subse¬ 
quent  study,  GPS  and  DSM  are  using  a  common  mission  console  and 
common  software.  Furthermore,  analysis  has  shown  that  the  GPS/DSM 
common  mission  console  meets  almost  all  of  the  salient  requirements  of 
the  SOPC  digital  television  equipment.  This  appears  to  be  a  fruitful  area 
and  is  the  subject  of  an  ongoing  effort. 

Adapting  Commercial  Processors  to  Command  and  Control  Interfaces 

Control  centers  in  general  face  the  problem  of  interfacing  commercial 
processors  with  standard  interfaces  to  the  outside  world  of  telemetry, 


tracking  command  and  displays  which  oftan  have  specialized  and  different 
interface!.  The  solutions  to  this  problem  are  complex  and  varied  and  tend 
not  to  be  useful  for  multiple  projects.  A  typical  approach  is  to  use  a  sat  of 
minicomputers  but  this  tends  to  be  data  rate  limited  and  to  incur  significant 
software  costs.  A  more  generalized  solution  is  to  adapt  a  commercial  data 
controller  with  a  set  of  plug-in  cards  on  the  outboard  side.  This  approach 
has  the  advantages  of  high  data  rates,  more  general  usage,  little  software 
impact  and  being  nearly  a  commercial  solution.  Effort  in  this  area  is 
continuing 

Communications  Interface  System 


A  significant  portion  of  a  communications  interface  system  is  the 
telemetry,  tracking  and  command  processing  system  and  is  a  basic  com¬ 
ponent  of  control  con  ten.  Typical  functions  performed  by  a  "front  end" 
indude  preprocessing,  recording  and  distribution  of  telemetry,  tracking, 
command,  video,  voice  and  miscellaneous  data  both  internally  and 
extarndly  to  the  control  center.  Analysis  has  shown  that  the  DSM  (hence, 
SOC)  front  end  is  a  subset  of  the  one  baselined  for  SO  PC  and  can  be 
augmented  to  meet  SOPC  requirements.  The  DSM  based  solution  is  poten¬ 
tially  simpler,  thus  less  expensive  to  acquire  and  operate.  Additionally,  the 
co-location  of  SOC  and  SOPC  offers  such  benefits  as  reduced  maintenance 
and  training.  As  before,  further  analysis  in  this  area  is  continuing. 

Summary 

Further  development  of  the  commonality  concept  is  being  pursued 
by  a  common  systems  development  group  established  by  FSD  in  Gaithers¬ 
burg  and  in  other  FSO  locations  such  as  Houston.  An  In-house  effort,  the 
group's  primary  objective  is  to  develop  system-level  software  which  can  be 
used  across  multiple  present  and  future  command  and  control  projects. 

Sturfes  convincingly  show  that  commonality  makes  both  sound 
technical  and  business  sense.  Preliminary  analysis  of  the  potential  for 
commonality  in  application  software  such  at  telemetry,  trajectory,  and 
command  and  control  has  shown  the  possibility  of  establishing  common 
application  software  kernels  which  could  be  used  across  projects.  Thus,  the 
potentiel  exists  for  carrying  this  commonality  beyond  the  system-level 
software  into  application  programs.  In  the  hardware  area,  multiple  project 
use  of  special  equipment,  a  trend  towards  a  more  commercial  solution  and 
common  man-machine  Interfaces  hold  great  promise. 

Commonality  is  a  concept  that  has  matured  within  FSD  and  is  cur¬ 
rently  in  practice,  reducing  cost  and  technical  risk  and  improving  software 
scheduling. 


(1)  Georgs  A.  Gaxiola,  "Commonality  of  Real-Time  Command  and 
Control,"  IBM/FSO  Technical  Directions,  Vol.  7.  No.  3,  pp. 
2-4:  Fall/Winter  1981. 

(21  Data  System  Modernization  Tracking  and  Orbit  Determination 
Specification  (CPCI  02)  May  1961 

Appendix  II 

Contract  No.  F0469061-C-0003 

(3)  Goddard  Trajectory  Determination  System  Orbit  Determina¬ 
tion  Subsystem  Methematical  Specification  March  1972 

Contract  No.  NASS-1 1790,  Task  No.  184 
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\  ABSTRACT 

V 

The  Consolidated  Space  Operations 
Center  (CSOC)  is  being  built  in  the  Colo¬ 
rado  Springs  area  to  conduct  DOD  space 
operations.  Its  Satellite  Operations 
Complex  and  its  Shuttle  Operations  and 
Planning  Complex  will  be  functionally 
similar,  respectively,  to  the  Air  Force 
Satellite  Test  Center  at  Sunnyvale, 
California,  and  the  NASA  Johnson  Space 
Center  in  Houston.  CSOC  Communications 
(CSOC-CS)  will  be  common  to  both  missions 
and  will  tie  CSOC  to  Air  Force  and  NASA 
nodes  and  networks. 

CSOC-CS  faces  a  number  of  challeng¬ 
es:  functional  replication,  multiple  net¬ 

work  interfaces,  and  evolution  of  other 
systems  and  philosophies.  The  problem  is 
further  compounded  by  an  existing  system 
that  is  still  evolving  and  by  a  compressed 
schedule,  as  CS  is  the  lead  CSOC  segment. 

T 

INTRODUCTION 

Space,  the  final  frontier  of  mankind, 
has  become  a  center  of  activity  as  the 
nations  of  the  world  exploit  it  through 
better  communications,  weather  forecast¬ 
ing,  geological  exploration  and  other  uses 
that  enrich  the  lives  of  their  citizens. 
The  United  States  has  done  all  of  these, 
as  well  as  maintaining  a  large  number  of 
space  assets  to  assure  its  national  secur¬ 
ity  as  depicted  in  Figure  1. 

CSOC 

Today  the  National  Aeronautics  and 
Space  Administration  (NASA)  and  Department 
of  Defense  (DOD)  operate  two  separate 
global  networks.  Because  of  economic,  op¬ 
erational  and  mission  considerations  and 
to  lessen  the  burden  on  NASA,  DOD  has  de¬ 
cided  to  build  and  operate  a  Consolidated 
Space  Operations  Center  (CSOC  . 


CSOC,  while  providing  enhanced  capa¬ 
bilities  to  meet  future  traffic  demands, 
will  certainly  fulfill  the  nation's  need 
for  an  endurable  and  secure  facility  for 
the  command  and  control  of  DOD  Shuttle  and 
satellite  missions. 

CSOC  will  be  located  at  Colorado 
Springs  and  is  the  flagship  of  the  new 
Space  Command  and  the  centerpiece  of  the 
emerging  Air  Force  Satellite  Control  Net¬ 
work  (AFSCN).  Figure  2  shows  this  per¬ 
spective.  Since  a  communications  capa¬ 
bility  is  the  heart  of  an  effective  com¬ 
mand  and  control  system,  the  success  of 
the  AFSCN  depends  on  the  availability  of 
an  endurable  communications  network. 

CSOC  Segments 

CSOC,  from  the  procurement  point  of 
view,  is  divided  into  seven  segments,  as 
shown  in  Figure  3,  with  the  Communications 
Segment  (CS)  as  the  cement  that  holds  the 
segments  together.  In  the  external  sense, 
CS  provides  extensive  connectivities  to 
every  critical  node  of  the  AFSCN,  as  shown 
in  Figure  4. 

Communications  Segment  (CS) 

CSOC  communications  provides  complete 
capabilities  to  satellite  missions  and 
Shuttle  missions  and  designated  capabili¬ 
ties  to  colocated  program  elements  (CPE) 
such  as  the  Global  Positioning  System 
(GPS)  and  connectivities  to  National  Com¬ 
mand  Authority  ( NCA )  through  SPADOC/NCMC. 
As  the  cornerstone  of  CSOC  activation  and 
test  activities,  the  CS  must  be  acquired 
promptly,  managed  properly,  and  designed, 
developed,  installed  and  operated  in  a 
most  cost-effective  manner. 

CHALLENGES 

The  Air  Force  Satellite  Control  Net¬ 
work  must  work  harmoniously  to  satisfy  its 
designated  missions.  The  key  nodes  of  the 
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network  must  also  share  each  other's  re¬ 
sponsibilities  under  certain  conditions. 
The  current  concept  of  operations  calls 
for  such  a  capability,  and  it  is  referred 
to  as  interoperability  between  paired 
nodes.  For  example,  the  Air  Force  Satel¬ 
lite  Control  Facility  (AFSCF)  must  be 
fully  interoperable  with  the  Satellite 
Operations  Complex  (SOC)  of  CSOC.  Simi¬ 
larly,  Johnson  Space  Center  (JSC)  which 
currently  operates  the  Shuttle,  must  be 
interoperable  with  the  Shuttle  mission 
portion  of  CSOC,  or  Shuttle  Operations  and 
Planning  Complex  (SOPC). 

AFSCN's  success  also  largely  depends 
on  successfully  integrating  the  full  capa¬ 
bilities  of  the  elements  of  the  network. 
Therefore,  compatibility,  commonality,  and 
standardization  are  key  concepts  in  CSOC 
definition.  The  concepts  apply  not  only 
to  current  systems  but  also  to  other 
parallel  developments  such  as  the  Data 
System  Modernization  (DSM)  program  for 
AFSCF,  the  NAVSTAR  Global  Positioning 
System  (GPS)  and  the  Defense  Meteorolog¬ 
ical  Satellite  Program  (DMSP). 

It  is  indeed  a  challenge  to  design  a 
system  under  these  circumstances.  To 
understand  this  challenge  and  to  provide  a 
framework  for  understanding  the  applied 
solutions,  it  is  useful  to  picture  the 
challenge  in  terms  of  the  three  major 
facets  or  dimensions  of  the  design  prob¬ 
lem.  This  is  illustrated  in  Figures  5  and 
6.  These  are  (1)  fitting  into  both  the 
DOD  and  NASA  worlds,  (2)  functional  repli¬ 
cation,  and  (3)  time.  Whenever  we  have  to 
specify  or  design  a  new  element  for  the  CS 
system,  we  have  to  address  these  dimen¬ 
sions. 

Fitting  into  Two  Worlds 

Over  the  years  NASA  and  dod  have  fol¬ 
lowed  their  own  paths  and  have  achieved 
separate  levels  of  maturity  i:  communica¬ 
tions  capabilities.  Each  evolved  around 
different  architectural  and  environmental 
considerations.  For  example,  the  NASA 
Telemetry,  Tracking  and  Command  (TT&C) 
frequencies  and  signal  structures  were 
markedly  different  from  that  of  AFSCF's 
mainstay,  the  Space  Ground  Link  Subsystem 
(SGLS)  TT&C  system.  Other  differences 
exist  in  operations  and  maintenance  phi¬ 
losophies,  security  and  data  privacy  con¬ 
cepts,  and  management  techniques.  All 
these  differences  have  had  an  effect  on 
equipment  design.  Thus,  the  first  CS 
question  we  answer  is  "Will  it  fit  into 
the  NASA  world,  or  the  DOD  world,  or  some 
combination  of  both?" 


Functional  Replication 

Here  is  the  simplest  solution  avail¬ 
able.  Buy  an  exact  duplicate  of  selected 
pieces  of  equipment  from  the  AFSCF  and 
Johnson  Space  Center,  install  and  test 
with  no  problems,  and  be  within  budget. 
Unfortunately,  in  most  cases  this  just 
won’t  work  for  several  reasons: 

1.  Design  may  be  location  dependent. 

2.  Equipment  may  not  be  available. 

3.  Functional  requirements  may  be 
different. 

4.  Current  designs  may  have  flaws. 

5.  Simpler,  cheaper,  or  more  effi¬ 
cient  solutions  may  be  available. 

We  have  to  take  all  these  into  ac¬ 
count  and  attempt  to  strike  a  cost  versus 
performance  balance,  selecting  that  design 
which  gives  us  the  required  functions  at 
lowest  cost  and  schedule  risk.  This  has 
led  to  the  term  "functional  replication,” 
to  describe  that  twilight  zone  between 
complete  off-the-shelf  duplication  and 
totally  new  design  where  all  required 
functions  are  satisfied. 

Time 

A  third  basic  question  we  have  to 
consider  is  "What  will  the  rest  of  the 
world  look  like  when  we  bring  our  communi¬ 
cations  segment  into  operation?"  This 
leads  us  into  some  speculation  on  programs 
we  know  about,  as  well  as  some  crystal 
ball  gazing  into  some  very  hazy  areas. 
The  AFSCF  itself  is  currently  undergoing 
change:  the  DSM  program,  new  wideband 

connectivities  and  modifications  to  the 
AFSCF  Remote  Tracking  Rites  are  some 
examples.  The  colocated  program  elements 
are  also  undergoing  changes,  such  as  the 
incorporation  of  DMSP  terminal  capabili¬ 
ties  into  RTS,  and  introduction  of  Ad¬ 
vanced  Remote  Tracking  Stations  (ARTS). 
The  birth  of  Space  Command  and  the  mod¬ 
ernization  of  NCMC,  including  the  intro¬ 
duction  of  the  Defense  Satellite  Communi¬ 
cations  System  (DSCS)  terminal  into  the 
NCMC  is  also  important  to  note.  NASA  too 
is  moving  away  from  reliance  on  its  God¬ 
dard  Spaceflight  Tracking  and  Data  Network 
{ GSTDN )  to  Tracking  and  Data  Relay  Satel¬ 
lite  System  (TDRSS)  based  connectivities. 
The  growth  systems  to  be  considered  in¬ 
clude  MILSTAR  and  the  common  mobile  con¬ 
trol  systems  which  require  the  usage  of 
higher  TT&C  frequencies.  CSOC-CS  must 
remain  compatible  in  this  fast  moving 
world . 


The  hazy  areas  include  conceptual  and 
philosophical  matters  which  are  in  a  state 
of  flux  and  may  or  may  not  be  the  same  in 
the  future  as  they  are  today.  Figure  7 
points  out  some  of  these  issues. 


INITIATIVES 

To  meet  the  challenges  we  have  just 
identified,  many  initiatives  have  been 
taken.  We  will  highlight  nine  of  these 
and  show  how  they  r  ply  to  the  challenges. 
The  initiatives  fall  into  three  categor¬ 
ies:  management,  acquisition,  and  engi¬ 

neering  (Figures  8  and  9).  None  of  the 
initiatives  represent  brand  new  ideas,  but 
rather  are  extensions  or  adaptations  of 
good  management  and  engineering  practices 
tailored  to  our  application  and  environ¬ 
ment  . 

MANAGEMENT 

The  three  management  initiatives  we 
are  highlighting  are  (1)  assigning  admin¬ 
istrative  communications  to  Air  Force  Com¬ 
munications  Command  (AFCC) ,  (2)  use  of  an 

integration  contractor,  and  (3)  use  of 
functional  working  groups  and  committees 
(Figure  10). 

AFCC  Role 

In  line  with  our  philosophy  of  func¬ 
tional  replication  and  avoiding  unneces¬ 
sary  new  development  wherever  possible,  we 
identified  the  administrative  communica¬ 
tions  area,  i.e.,  admin  telephone  switch, 
communications  message  center,  AUTOVON, 
AUTODIN,  and  AUTOSEVOCOM  connectivity,  as 
an  area  where  a  standard  approach  would 
work  best.  As  a  result,  the  SPO  has 
selected  AFCC  as  a  partner  to  help  imple¬ 
ment  admininistrative  communications. 
AFCC  has  a  wealth  of  experience  in  this 
area,  fully  understands  administrative 
communications,  and  has  a  mature  opera¬ 
tions  and  maintenance  philosophy.  With 
AFCC  as  a  partner,  we  get  the  additional 
bonus  in  being  able  to  cross-fertilize 
ideas  with  a  command  whose  forte  is  oper¬ 
ations  and  maintenance  of  communications 
systems . 

Integration  Support  Contract 

In  the  spring  of  1982,  Air  Force 
Space  Division  awarded  the  CSOC  Integra¬ 
tion  Support  Contract  (CISC)  to  TRW.  This 
has  brought  on  board  extensive  expertise 
to  complement  the  skills  resident  in  the 
CSOC  Program  Office.  A  large  part  of  the 
system  integration  effort  is  defining  and 
engineering  the  interfaces  necessary  to 
fit  into  the  DOD  and  NASA  worlds  and 
making  it  work  as  a  system.  TRW  is  also 


solidifying  various  philosophical  issues 
and  has  authored  systems  engineering, 
maintenance  and  support  concepts. 

Groups  and  Committees 

We  have  established  many  working 
groups  and  steering  committees,  some  of 
which  are  shown  in  Figure  10.  We  have 
found  these  groups  especially  useful  in 
solving  many  of  the  functional  problems 
which  cut  across  CSOC  product  lines.  In 
many  cases,  these  groups  also  provide  the 
forums  to  raise  and  work  issues  crucial  to 
interfacing  CSOC  with  the  external  world. 
Additionally,  the  groups  have  provided 
impetus  to  solidifying  and  settling  philo¬ 
sophical  issues  early  enough  to  be  incor¬ 
porated  into  the  design. 

ACQUISITION 

The  nature  of  the  design  challenges 
has  also  affected  our  acquisition  ap¬ 
proach.  Ideas  have  been  implemented  which 
have  worked  well  in  other  programs.  These 
are  (1)  two-phase  strategy,  (2)  use  of 
analytical  tasks,  and  (3)  an  incremental 
support  capability  concept  (Figure  11). 

Two-Phase  Strategy 

Rather  than  a  single  contract  for  the 
entire  Communications  Segment  (CS)  acqui¬ 
sition,  we  are  going  to  develop  the  system 
in  two  phases.  The  first  phase  will  be  a 
one  year  definition  effort  with  two  con¬ 
tractors  competing  in  parallel  to  provide 
a  set  of  specifications  for  the  CS.  Then, 
one  of  these  designs  will  be  selected  for 
Phase  2  implementation,  which  will  span  60 
months.  Several  advantages  accrue  from 
this  approach.  It  allows  considerable  in¬ 
vestigation  and  solidification  of  other 
product  lines  and  concepts  prior  to  actu¬ 
ally  selecting  a  design  approach;  it  in¬ 
jects  elements  and  creativity  into  the 
design  process;  and  it  permits  the  use  of 
timely  special  studies  in  areas  that  are 
weak  or  hazy.  These  special  studies  are 
called  analytical  tasks,  and  are  discussed 
separately . 

Analytical  Tasks 

It  has  always  been  easier  to  identify 
weak  or  hazy  areas  than  it  has  been  to 
find  their  solutions.  Therefore,  we  have 
used  the  analytical  task  as  a  device  to 
generate  these  solutions.  Each  contractor 
in  Phase  One  will  analyze  and  provide  rec¬ 
ommended  solutions  for  fifteen  problem 
areas  that  are  identified  in  the  Statement 
of  Work  and  are  as  shown  in  Figure  11. 
These  fifteen  represent  the  most  difficult 
design  areas  and  require  the  closest  scru¬ 
tiny  and  study  before  design  approaches 
are  finalized. 


Incremental  Support  Capabilities 

This  is  our  "buy  it  by  the  pound" 
approach  for  the  Communications  Segment 
(Figure  12).  The  CS  is  required  to  sup¬ 
port  different  capabilities  at  different 
times.  In  general,  the  DOD  world  will  be 
connected  first  and  CSOC  will  become  oper¬ 
ational  in  phases  before  the  NASA  world  is 
integrated  into  the  system.  This  means 
that  other  CSOC  segments  will  be  in  dif¬ 
ferent  stages  of  design  and  development 
when  phase  two  of  the  CS  contract  begins. 
Rather  than  design  and  build  everything  at 
once,  the  CS  will  be  activated  in  incre¬ 
ments  depending  on  when  its  capabilities 
and  functions  are  required.  This  permits 
for  better  design  solidification  of  the 
out-year  elements  before  communications 
are  designed  for  them.  In  addition, 
paying  for  the  capabilities  as  we  need 
them  produces  a  more  acceptable  funding 
prof ile . 

ENGINEERING 

Good  engineering  solutions  generally 
arise  from  (a)  identification  of  existing 
design  limitations,  (b)  establishment  of 
design  considerations,  and  (c)  the  enumer¬ 
ation  of  detailed  requirements.  These  are 
shown  in  Figure  13.  A  subset  of  the 
existing  design  limitations  is  shown  in 
Figure  14.  The  design  considerations  are 
extracted  from  the  mission  needs  while  the 
design  requirements  synthesis  will  be  via 
a  combination  of  the  mission  needs  state¬ 
ment  and  the  derivation  of  functional 
characterizations  fro'  the  operations  con¬ 
cept,  within  the  technology  constraints. 
Figure  15,  for  example,  is  a  partial  look 
at  the  data  rates/needs  of  several 
mission/program  elements  that  must  be 
addressed  in  the  engineering  solution. 

So  the  problem  reduces  to  this. 
"What  is  the  balancing  act  that  the  CS 
designer  must  put  together  to  satisfy  the 
combined  needs  of  DOD  and  non-DOD  users?" 
Figure  16  depicts  some  of  the  network 
related  issues,  while  Figure  17  shows  that 
the  communications  processing  designer 
must  be  provided  with  a  specific  set  of 
data  for  his  design  and  not  a  catalog  or  a 
shopping  list. 

These  problems  provide  but  a  sample 
of  the  size  and  scope  of  the  engineering 
issues  to  be  resolved  before  CSOC  becomes 
a  reality.  To  meet  the  engineering  chal¬ 
lenge  now  and  in  the  future,  we  have  in¬ 
stituted  three  important  engineering 
ground  rules  (Figure  18): 

(1)  Use  Pre-Planned  Product  Improve¬ 
ment  ( P^ I )  , 


(2)  Capitalize  on  other  programs,  and 

(3)  Maintain  Transparency  of  Communi¬ 
cations. 

Pre-Planned  Product  Improvement  (P-^I) 

P^I  has  been  a  most  important  concept 
in  our  acquisition  effort.  It  simply 
means  designing  with  a  built-in  capability 
for  future  growth.  One  of  the  tools  used 
to  ensure  that  the  concept  is  implemented 
is  designating  it  an  analytical  task  for 
Phase  One  of  the  acquisition.  In  this 
effort,  both  contractors  will  look  at  the 
future  architecture  of  space  systems  and 
will  identify  specific  areas  in  which  to 
apply  the  P^I  concept.  p’l  provides  the 
best  insurance  that  CSOC  will  be  a  system 
for  the  future. 

Capitalize  on  Other  Programs 

Wherever  possible,  CSOC  communica¬ 
tions  is  capitalizing  on  other  programs, 
using  facilities,  designs,  studies,  or 
options  wherever  possible  to  keep  from  re¬ 
inventing  the  wheel,  to  get  the  best  bang 
for  the  buck,  and  to  promote  commonality. 
For  example,  we  are  piggy-backing  a  NASA 
contract  to  purchase  multiplexer/demulti¬ 
plexer  ( MDM )  for  the  NASA  communications 
links;  and  we  are  using  a  Defense  Satel¬ 
lite  Communications  System  (DSCS)  facility 
serving  other  DOD  missions  for  some  CSOC 
connectivity.  There  is  also  a  complicated 
options  linkage  between  the  CSOC  program 
and  other  AFSCF  programs  where  both  may 
capitalize  on  each  other's  efforts. 

Communications  Transparency 

This  concept,  simply  stated,  is  that 
communications  systems  should  be  kept  as 
standard,  common  and  flexible  as  possible 
by  avoiding  embedded  mission  or  location 
dependent  functions  and  by  maintaining 
common  standards  on  all  communications 
links.  This  is  a  key  initiative  which 
allows  interoperability  (control  of  range 
assets  by  several  operations  centers 
within  the  same  organization)  and  inter¬ 
netting  (allowing  an  operations  center  to 
control  spacecraft  using  ground  stations 
belonging  to  another  organization). 
Implicit  in  this  concept  is  that  CSOC  must 
speak  a  language  common  to  the  nodes  to 
which  it  is  connected.  For  this  reason, 
CSOC  is  providing  format  conversion  where 
necessary  to  maintain  transparency  to  the 
user. 

The  transparency  concept  also 
enhances  survivability  of  the  AFSCN  by 
commonality  of  alternative  paths.  For 
example,  in  Figure  19,  the  alternate  paths 
to  Remote  Tracking  Sites  still  remain, 
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even  if  a  primary  route  out  of  CSOC  via 
DSCS  becomes  unavailable  or  inoperative. 
Thus,  the  transparency  concept  helps  us  to 
perform  our  mission  better,  even  under 
adverse  conditions. 


SUMMARY 

In  meeting  the  challenges  presented 
by  CSOC  communications  acquisition,  many 
initiatives  have  been  implemented,  nine  of 
which  have  been  presented  in  this  paper. 
As  a  result  of  the  efforts  thus  far,  a 
communications  architecture  has  emerged 
(Figure  20).  We  are  confident  that  the 
basic  architecture  is  sound  and  that  it 
will  continue  to  evolve  successfully  to 
meet  the  needs  of  CSOC  as  a  system  for  the 
1980's  and  beyond. 
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Cen  James  V.  Hartinger 
Commander 
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General  James  V.  Hartinger  is  Commander  of  the  (JSAF 
Space  Command  (SPACECOM)  and  Commander  in  Chief  of 
the  North  American  Aerospace  Defense  Command  (NORAD), 
with  both  headquarters  at  Peterson  Air  Force  Base,  CO. 

General  Hartinger  is  fmm  Middleport,  Ohio,  where  he  was 
drafted  into  the  Infantry  in  July  1943  and  attained  the  grade  of 
sergeant.  Following  World  War  II.  he  entered  the  United  States 
Military  Academy  at  West  Point,  New  York.  Upon  graduation 
in  1949,  he  received  a  bachelor  of  science  degree  and  was 
commissioned  as  a  second  lieutenant  in  the  United  States  Air 
Force. 

General  Hartinger  has  been  a  career  long  fighter  pilot.  He  at¬ 
tended  pilot  training  at  Randolph  AFB,  TX.  and  Williams  AFB, 
AZ,  where  he  graduated  in  August  1950.  He  then  was  reas¬ 
signed  as  a  jet  fighter  pilot  with  the  36th  Fighter  Bomber  Wing 
at  Furstenfeldbruck,  Germany,  and  in  December  1952  joined 
the  474th  Bomber  Wing  at  Kunsan  Air  Base,  Korea,  where  he 
flew  his  first  combat  missions  in  the  F-84  Thunderjet. 

In  July  1953,  he  returned  to  Williams  AFB  as  a  gunnery  in¬ 
structor,  and  in  August  1954  was  transferred  to  Stewart  AFB, 
NY,  as  a  fightr .  pilot  and  air  operations  officer  in  the  331st 
Fighter  lntercep:or  Squadron.  During  this  period,  he  attended 
Squadron  Office.'  School  at  Maxwell  AFB.  AL. 

In  June  1958,  General  Hartinger  began  a  four  year  tour  in 
the  Directorate  of  Requirements,  HQ  USAF,  in  the  Pentagon. 
After  receiving  a  master's  degree  in  business  administration  at 
the  George  Washington  University  in  1963,  he  was  assigned  to 
Hickam  AFB,  HI,  in  the  Directorate  of  Plans,  HQ  Pacific  Air 
Forces. 

General  Hartinger  graduated  from  the  Industrial  College  of 
the  Armed  Forces  at  Fort  McNair,  Washington,  D.C.,  in  June 


1966.  Thereafter,  he  received  F-4C  Phantom  replacement 
training  with  the  43rd  Tactical  Fighter  Squadron  at  MacDill 
AFB,  FL,  and  proceeded  to  Vietnam.  From  December  1966  to 
December  1967,  he  was  assigned  to  HQ  7th  Air  Force  at  Tan 
Son  Nhut  Air  Base,  during  which  time  he  completed  more 
than  100  aerial  combat  missions. 

In  1968,  General  Hartinger  was  the  F-lll  test  director  at 
Nellis  AFB,  NV,  and  then  assumed  command  of  the  famed 
"Flying  Tigers."  the  23rd  Tactical  Fighter  Wing,  at  McConnell 
AFB,  KS. 

General  Hartinger  became  Deputy  Chief  of  Staff/Plans  at 
North  American  Air  Defense  Command,  Ent  Air  Force  Base, 
CO,  in  June  1 970  and  then  moved  to  Maxwell  AFB,  AL,  in  May 
1973,  as  Commandant  of  the  Air  War  College. 

From  1975  to  1980,  General  Hartinger  was  Commander  of 
both  Tactical  Air  Command  Air  Forces,  9th  Air  Force  at  Shaw 
AFB,  SC,  and  12th  Air  Force  at  Bergstrom  AFB,  TX.  He 
became  C1NCNORAD  on  1  January  1980,  and  Commander, 
SPACECOM,  on  1  September  1982. 

His  military  decorations  and  awards  include  the  Defense 
Distinguished  Service  Medal,  the  Distinguished  Service  Medal 
with  one  oak  leaf  cluster,  Legion  of  Merit  with  one  oak  leaf 
cluster,  Distinguished  Flying  Cross,  Air  Medal  with  eight  oak 
leaf  clusters,  Air  Force  Commendation  Medal,  and  Combat 
Readiness  Medal.  He  is  also  an  honorary  Doctor  of  Military 
Science. 

General  Hartinger  is  married  to  the  former  Mickey  Christian 
of  Mullens,  WV,  and  has  three  children:  Jimmer.  Kris,  and 
Mike. 
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.  ABSTRACT 

V 

This  article  examines  the 
international  legal  restrictions 
on  the  military  use  of  outer 
space  and  how  those  restrictions 
have  been  interpreted  by  the  two 
major  space  powers  in  their 
actual  or  projected  utilization 
of  space  for  military-related 
purposes.  It  also  discusses  the 
fragile  nature  of  the  legal 
regime  which  has  been  created  by 
international  treaties.  These 
treaties  will  probably  be 
suspended  or  terminated  during 
time  of  hostilities  between  the 
parties. 


INTRODUCTION 

In  the  not  too  distant  past,  the 
international  legal  community  could  take 
pride  in  the  fact  that  they  had  been 
successful  in  establishing  a  rudimentary 
legal  regime  governing  certain  activities 
by  States  in  outer  space.  The  success  of 
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the  Committee  on  the  Peaceful  Uses  of 
Outer  Space  (COPUOS)  in  developing 
certain  broad  legal  principles  is 
considered  by  many  members  of  the  legal 
profession  as  one  of  the  finest  examples 
of  law  being  in  the  vanguard  of  a  new 
environment.  There  is  no  doubt  that  the 
spectacular  success,  as  reflected  by  the 
numerous  nations  that  have  become  parties 
to  the  Treaty  on  Principles  Governing  the 
Activities  of  States  in  the  Exploration 
and  Use  of  Outer  Space  including  the  Moon 
and  Other  Celestial  Bodies,!./  was  a 
brilliant  accomplishment  of  the  world 
legal  community.  The  fact  that  the  Outer 
Space  Treaty  was  followed  shortly  by 
three  companion  treaties!/  added  to 
the  prestige  and  relevance  of  inter¬ 
national  space  law.  Only  in  the  last  few 
years,  with  the  difficulty  posed  by  some 
controversial  provisions  in  the  Agreement 
Governing  the  Activities  of  States  on  the 
Moon  and  Other  Celestial  Bodies  and  the 
various  intractable  issues  pending  before 
COPUOS,  has  the  momentum  abated.!/ 

With  the  four  treaties  on  outer 
space  activities  having  been  generally 
accepted  by  a  significant  portion  of  the 
world  community,  the  international  legal 
community  began  the  task  of  interpreting 
the  vague  terminology  that  had  been 
necessary  to  incorporate  into  the 
treaties  due  to  the  consensus  procedure 
utilized  by  COPUOS.  Articles  in  all 
languages  cascaded  forth  attempting  to 
analyze  the  somewhat  obscure  legal  regime 
that  had  been  created.!/  one  area 
that  attracted  attention  was  the  attempt 
to  define  what  was  meant  by  the  words 
"peaceful  use"  as  those  terms  appear  in 
the  Outer  Space  Treaty.  While  those 
academic  exercises  were  occuring  over  the 
definition  of  peaceful  use,  the  world 
space  powers  were  giving  clear  meaning  to 
such  concepts  by  the  actual  military  uses 
that  they  were  making  of  the  outer  space 
environment. 


PEACEFUL  USE 


The  words  "peaceful  uses  of  outer 
space"  are  not  a  legal  term  of  art.  Many 
International  lawyers  have  attempted  to 
turn  what  is  essentially  a  general 
philosophical  description  into  specific 
legal  restrictions.  Essentially  the 
meaning  of  "peaceful  use"  varies  from  one 
viewer's  perspective  to  another's  as  well 
as  from  one  document  or  treaty  to 
another.  Therefore,  because  it  is  not  a 
term  of  art,  one  must  look  to  other 
sources  to  ascertain  the  meaning.  In 
this  regard,  international  lawyers  have 
failed  to  give  sufficient  importance  to 
the  actual  practice  of  the  states  in 
arriving  at  a  workable  and  acceptable 
definition  of  the  peaceful  use  clause  as 
contained  in  the  Outer  Space  Treaty. 

Initially  there  were  two  schools  of 
thought  on  the  meaning  of  peaceful  use. 
The  first  held  that  in  the  context  of  the 
Outer  Space  Treaty,  peaceful  use  meant 
non-aggressive  use  of  outer  space.  Under 
this  view  the  only  military  restrictions 
were  those  specifically  stated  in  the 
applicable  multilateral  and  bilateral 
treaties,  including  the  United  Nations 
Charter,  to  which  individual  states  were 
parties.  The  second  school  of  thought 
equated  peaceful  use  to  non-military  uses 
of  outer  space.  This  later  definition 
was  quickly  determined  to  be  rather 
impractical.  It  was  early  realized  that 
virtually  all  uses  of  outer  space  could 
have  military  application.  Legal 
scholars  then  eventually  posed  the 
question  in  a  different  manner.  They 
stated  that  instead  of  attempting  to 
classify  a  particular  space  activity  as 
military  or  non-military,  a  better 
approach  would  be  to  ask  whether  the 
activity  in  question  is  consistent  with 
the  requirements  of  international  law, 
including  the  United  Nations 
Charter.!/  It  should  be  remembered 
that  international  law,  including  the 
United  Nations  Charter,  does  not  prohibit 
military  activity  as  such.  It  only 
prohibits  the  threat  or  use  o  force  and 
acts  of  aggression.  The  United  Nations 
Charter  also  specifically  reiterates  the 
inherent  right  of  self-defense. 

subsequent  practices  and 

INTERPRETATION  OF  TREATIES 

In  order  to  give  this  latter 
approach  some  meaning,  the  actual 
practice  of  nations  that  have  the 
capability  of  operating  militarily  in  the 
outer  space  environment  becomes  vitally 
important  in  the  interpretation  of  the 
terms  of  the  applicable  treaty.  This,  of 
course,  may  raise  the  objection  that  the 
practices  of  a  few  states  that  are 


parties  to  a  multilateral  treaty  cannot 
provide  a  definitive  meaning  to  the  terms 
found  in  a  multilateral  treaty.!/ 

However,  because  of  the  unique  environ¬ 
ment  of  outer  space,  the  relatively  few 
states  that  can  utilize  outer  space  for 
military  activity  and  the  manner  in  which 
the  legal  rules  governing  outer  space 
activities  have  been  developed,  the 
actual  practices  of  the  two  nations  that 
effectively  use  outer  space  for  military 
related  purposes  should  be  given  great 
weight,  if  not  controlling  weight,  to  the 
definition  of  such  nebulous  terms  as 
"peaceful  use". 

Section  III  of  the  Vienna  Convention 
of  the  Law  of  Treaties,  promulgates  some 
general  rules  for  the  interpretation  of 
international  agreements.  Under  Article 
31  (3)  it  states,  in  part: 

"There  shall  be  taken  into 
account,  together  with  the 
content . 

•  •  •  • 

(b)  Any  subsequent  practices  in 
the  application  of  the  treaty 
which  establishes  the  agreement 
of  the  parties  regarding  its 
interpretation. " 

The  use  of  the  actual  practice  of 
States  in  attempting  to  interpret  the 
meaning  of  an  agreement  is  most 
frequently  called  "practical"  or 
"conventional"  interpretation.  This 
so-called  "principle  of  subsequent 
conduct"  refers  to  any  behavior,  subse¬ 
quent  to  the  entry  into  force  of  an 
agreement,  which  appears  to  be  relevant 
or  useful  in  determining  the  continuing 
consensus  of  the  parties.!/  Lord 
McNair  stated  such  principle  in  the 
following  manner: 

"The  contracting  parties  may 
themselves  have  attached  a 
particular  meaning  to  the  terms  of  a 
treaty  either  impliedly  by  a  long 
course  of  conduct  or  by  expressed 
agreement  and  in  either  case  this 
agreed  meaning  may  be  either  a  bona 
fide  interpretation  of  an  obscure 
term  or  an  attempt  to  substitute  a 
new  stipulation  for  the  original 
one . "!/ 

In  general,  it  has  been  stated  that 
a  major  purpose  in  examining  the  subse¬ 
quent  actions  of  the  parties  is  that  of 
obtaining  an  exceptionally  reliable 
source  for  determining  their  genuine 
shared  expectations.  The  weight  to 
accord  subsequent  practices  of  the 
parties  will  vary  from  case  to  case,  but 
no  respected  commentator  on  interpreta¬ 
tion  has  failed  to  endorse  the  principle, 


although  some  have  cautioned  ayainst 
placing  too  much  emphasis  upon  such 
evidence,  especially  if  it  appears  to 
conflict  with  the  initial 
expectations . *£/ 

Judge  Alvarez  has  commented  that  "a 
treaty.  .  .that  once  has  been  established 
acquires  a  life  of  its  own.  Consequent¬ 
ly,  in  interpreting  it,  we  must  have 
regard  to  the  exigencies  of  contemporary 
life  rather  than  the  intentions  of  those 
who  framed  it.“Ai/  And  finally, 

McNair  states  that  any  theory  of 
interpretation  should  be  one  which  is 
favorable  to  the  freedom  of  states  and 
places  the  less  restriction  on  its 
liberty  of  action. !£/ 

In  evaluating  these  views  of  the 
importance  of  subsequent  practice,  it 
becomes  readily  apparent  that  the  actual 
practice  of  the  space  powers  becomes 
fundamentally  important  to  any 
interpretation  of  terms  found  in  the 
treaties  regarding  the  regime  of  outer 
space.  This  subsequent  practice  theory 
of  interpretation  reflects  the  true 
expectations  of  the  space  powers  in  the 
contemporary  utilization  of  space  for 
military  defensive  purposes. 

ACTUAL  PRACTICE 

What  has  been  the  practice  of  the 
two  space  powers  since  the  Outer  Space 
Treaty  entered  into  force?  While  it  is 
somewhat  difficult  to  determine  exactly 
the  extent  of  military  use  of  outer  space 
by  the  space  powers  due  to  security 
classifications,  one  can  obtain  a  fairly 
good  idea  of  the  present  practices  by 
reviewing  current  media  reports  of  such 
activity.  There  appears  to  be  good  media 
evidence  that  the  Soviets  have  been  abU- 
to  develop  an  operational  anti-satell 
system,  and  the  Americans  have  stated 
that  they  are  pursuing  the  development  of 
their  own  anti-satellite  system. !£/ 

During  the  recent  Falkland/Malvinas  and 
Lebanese  crises,  it  was  reported  that 
both  the  Soviets  and  the  Americans  were 
actively  utilizing  reconnaissance 
satellites  to  obtain  military  intelli¬ 
gence  relating  to  the  conflicts.il/ 

There  is  little  question  that  both 
countries'  military  are  more  and  more 
relying  on  space  based  systems  for 
communication,  navigation,  early  warning, 
and  treaty  verif ication.  It  has  been 
estimated  that  70%  of  Soviet  satellites 
are  purely  military  in  their  application 
with  an  additional  15%  of  their  space 
activity  sharing  a  dual  role  with  the 
non-military  sector.  This  leaves  only 
15%  of  their  space  activity  to  civil 
scientific  endeavors .!£/  The  United 
States  has  indicated  that  over  40%  of  the 


cargo  of  the  space  shuttle  originates 
with  the  United  States  military,  and  for 
the  next  fiscal  year,  the  U.S.  military 
budget  for  space  related  projects  will 
exceed  the  budget  for  NASA.-Ls./ 

The  United  States  Air  Force  only  recently 
announced  the  creation  of  a  separate 
Space  Command  in  order  to  more  effective¬ 
ly  manage  the  growing  investment  in 
military  space  systems.il/  Both 
powers  appear  to  be  heavily  involved  in 
research  related  to  space  based  laser 
systems.!®/  The  litany  of 
military  uses  of  outer  space  by  the 
Soviets  is  extensive  and  probably  limited 
only  by  the  present  state  of  the  art  and 
the  few  restrictions  found  in  inter¬ 
national  agreements.  The  utilization 
of  space  for  self-defensive  purposes  has 
taken  place  and  with  it  the  interpreta¬ 
tion  of  peaceful  use  has  become  a  fait 
accompl i . 

SPECIFIC  RESTRICTIONS 

A  discussion  of  the  restrictions 
contained  in  both  multilateral  and 
bilateral  treaties  involving  the  space 
powers  is  necessary  in  order  to  realize 
the  present  limited  restrictions  on  the 
military  use  of  outer  space.  It  is  first 
important  to  reiterate  the  concept  that 
international  law  is  generally  proscrip¬ 
tive  in  nature — that  is,  what  is  not 
prohibited  is  normally  allowed.  Conse¬ 
quently,  very  few  military  activities  are 
barred  from  operation  in  the  outer  space 
environment . 

The  most  widely  accepted  prohibition 
concerning  military  activity  in  space  is 
found  in  the  Outer  Space  Treaty.  Article 
IV  of  that  treaty  prohibits  the  following 
military  related  activity:  (1)  Not  to 
place  in  orbit  around  the  earth,  install 
on  the  moon  or  any  other  celestial  body, 
or  otherwise  station  in  outer  space 
nuclear  or  any  other  weapons  of  mass 
destruction  and  (2)  Not  to  establish 
military  bases,  installations,  or 
fortifications,  test  any  type  of  weapons 
or  conduct  military  maneuvers  on  the  moon 
or  other  celestial  bodies. JL£/  weapons 
of  mass  destruction  include  biological 
and  chemical  weapons,  but  do  not 
include  laser  and  particle  beam  weapons 
systems  as  these  systems  can  be 
considered  "point"  weapons  and  not 
indiscriminate  weapons  of  mass 
destruction. ££/ 


Two  other  important  multilateral 
treaties  are  the  Treaty  Banning  Nuclear 
Weapons  Tests  in  the  Atmospheie,  In  Outer 
Space  and  Under  Water  and  the  Convention 
on  the  Prohibition  of  Military  or  any 
other  Hostile  Use  of  Environmental 
Modification  Techniques .1£/  The 


Limited  Test  Ban  Treaty  bans  all  nuclear 
explosions  in  outer  space.  The  Environ¬ 
mental  Modification  Treaty  specifically 
applies  to  the  outer  space  environment 
and  prohibits  the  military  or  other 
hostile  use  of  environmental  modification 
techniques  as  the  means  of  destruction, 
damaye  or  injury  to  any  other  State 
Party,  if  the  usage  has  widespread 
(several  hundred  square  kilometer  area), 
long  lasting  (approximately  a  season)  and 
has  severe  effects  (serious  or  signifi¬ 
cant  disruption  or  harm  to  human  life, 
natural  and  economic  resources  or  other 
assets).  Environmental  modification 
techniques  are  defined  as  any  technique 
for  changing  the  dynamics,  composition  or 
structure  of  the  earth  or  of  outer  space 
through  the  deliberate  manipulation  of 
the  natural  processes.  This  treaty  does 
not  prohibit  research,  development  and 
testing  of  environmental  modification 
techniques . 

In  addition  to  the  above  multi¬ 
lateral  treaties  that  restrict  military 
activity  in  outer  space,  there  are 
certain  bilateral  treaties  between  the 
United  States  and  the  Soviet  Union  that 
further  restrict  their  military 
operations  in  space.  The  treaty  on  the 
Limitation  of  Anti-Ballistic  Missile 
Systems,  with  Associated  Protocol, 
expressly  prohibits  the  development, 
testing  or  deployment  of  space-based  ABM 
systems  and  components .21/  An  ABM 
system  is  defined  as  "a  system  to  counter 
strategic  ballistic  missiles  or  the ' r 
elements  in  flight  trajectory."  Under 
the  terms  of  this  same  treaty,  the 
Parties  agree  not  to  interfere  with  each 
other's  national  technical  means  ( NTM )  of 
verification.  NTM  is  the  cryptic 
reference  to,  among  other  things,  imaging 
satellites  used  for  treaty  monitoring  to 
insure  compliance  with  the  ABM  treaty. 
Similar  NTM  provisions  are  found  in  the 
SALT  I  and  SALT  II  agreements. 

Another  multilateral  international 
agreement  that  has  important  application 
to  the  military  uses  of  outer  space  is 
the  United  Nations  Charter. 21/  The 
Outer  Space  Treaty  specifically  made  the 
United  Nations  Charter  part  of  the  legal 
regime  of  outer  space.  The  two  most 
important  parts  of  the  Charter  that 
directly  affect  military  operations  in 
space  are  Article  2(4)  and  Article  51. 

The  former  states  that  "All  Members  shall 
refrain  in  their  international  relations 
from  the  threat  or  use  of  force  against 
the  territorial  integrity  or  political 
independence  of  any  state  or  in  any  other 
manner  inconsistent  with  Purposes  of  the 
United  Nations."  Article  51  preserves  the 
customary  right  of  self-defense. 25/ 
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EFFECT  OF  HOSTILITIES  ON  TREATIES 

A  problem  that  is  often  ignored  when 
discussing  the  restrictions  on  the  mili¬ 
tary  uses  of  outer  space  is  the  effect  of 
hostilities  on  the  continuing  application 
of  the  terms  of  the  treaties  concerned. 
Practically  all  the  discussion  of  the 
military  application  of  outer  space 
revolves  around  the  military  uses  in 
peacetime.  However,  it  is  of  crucial 
importance  to  military  research,  develop¬ 
ment  and  contingency  planning  for  the 
effect  of  hostilities  on  certain  treaties 
be  appreciated.  It  is  of  similar 
importance  for  international  lawyers  to 
acknowledge  this  situation  in  order  that 
future  agreements  will  address  this 
anomal ly . 

There  is  general  agreement  that  the 
outbreak  of  hostilities  does  not  ipso 
facto  terminate  all  treaties.  The 
termination  or  suspension  of  treaties 
during  hostilities  depends  on  a  treaty's 
nature,  terms,  subject  matter  and  the 
intent  of  the  parties.  Other  than  these 
broad  guidelines,  current  international 
legal  principles  are  not  very  helpful  in 
this  area. 

If  it  is  clearly  stated  in  the  terms 
of  the  treaty  or  it  is  obvious  from  its 
content  that  the  treaty  is  to  apply  or  to 
become  operative  during  hostilities,  then 
there  is  little  problem.  For 
example,  the  1907  Hague  and  the  1949 
Geneva  Conventions  relating  to  the 
conduct  of  hostilities  are  clearly 
treaties  of  this  type.  However,  of  the 
treaties  concerning  restrictions  on  outer 
space  activity  by  the  military,  only  the 
Environmental  Modification  Treaty  by  its 
own  terms  remains  in  effect  during 
hostilities. 2®/ 


At  the  other  end  of  the  spectrum  is 
the  arms  limitation  or  disarmament  type 
of  treaty.  By  their  very  nature,  such 
treaties  are  incompatible  with  the  state 
of  armed  conflict  and  would  be  suspended 
or  terminated  during  hostilities.  In 
this  category  would  be  the  ABM 
Treaty2Z/  and  the  Nuclear  Test  Ban 
Treaty .2®/ 

Somewhere  in  between  the  treaties 
that  are  specifically  made  applicable 
during  hostilities  and  the  treaties  that 
are  clearly  incompatible  with  armed 
conflict  falls  the  Outer  Space  and 
related  Treaties. 22/  One  must,  then, 
resort  to  the  intentions  of  the  parties 
to  determine  whether  the  terms  of  the 
treaty  are  compatible  with  hostilities. 
The  issue  of  the  effect  of  hostilities  on 
the  Outer  Space  Treaty,  apparently 
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was  never  discussed  during  negotiations. 
However,  the  provisions  of  Article  IV  of 
the  Outer  Space  Treaty  would  appear  to  be 
incompatible  with  hostilities,  as  such 
provisions  are  basically  concerned  with 
the  areas  of  disarmament  and  demilitari¬ 
zation  zones.  Consequently,  during 
hostilities  it  would  seem  that  each  party 
w.uld  have  the  right  to  determine  the 
ent  to  which  it  considered  itself 
u'  and  by  the  obligations  of  Article  IV. 
Thus,  if  this  provision  is  deemed  to  be 
incompatible  with  the  state  of  armed 
conflict,  it  could  be  suspended, 
allowing,  for  example,  the  orbiting  or 
stationing  in  outer  space  weapons  of  mass 
destruction  and  the  militarization  of 
celestial  bodies.  The  same  would  appear 
true  of  the  other  companion 
treat ies.2£/  For  example,  the 
concept  that  an  astronaut  is  an  "envoy  of 
mankind,"  and  the  requirement  that  the 
holding  state  immediately  return  him  to 
his  home  country,  would  quickly  change  in 
time  of  hostilities  to  converting  an 
astronaut  who  is  found  in  hostile 
territory,  to  either  the  status  of 
prisoner  of  war,  a  civilian  detainee  or 
even  perhaps  he  could  be  considered  a 
spy.  Depending  on  various  factors,  the 
astronaut  could  then  only  rely  upon  the 
provisions  of  one  of  the  1949  Geneva 
Conventions  and  not  on  the  provisions  of 
the  Rescue  and  Return  Treaty.  The 
Registration  and  Liability  treaties  would 
also  be  one  of  the  first  casualties  of 
hostilities  between  the  parties,  as  the 
terms  of  these  treaties  are  not 
compatible  with  an  armed  conflict 
situation. 


It  is  recognized  that  the  above 
discussion  may  be  an  over  simplification 
of  the  effect  of  hostilities  on  space 
related  treaties.  Many  countries, 
because  of  the  unique  environment  of 
outer  space,  would  take  the  view  that 
supension  of  Article  IV  of  the  Outer 
Space  Treaty  restricting  military 
activity  affects  all  parties  to  the 
treaty.  They  could  argue  that  the  many 
references  to  peaceful  purposes  and  the 
concept  of  using  space  for  the  benefit  of 
all  mankind,  along  with  the  multilateral 
nature  of  the  treaty,  require  that  the 
treaty  remain  in  force  and  effect  during 
periods  of  armed  conflict.  However,  this 
opposing  view  is  left  to  other  authors  to 
explore.  It  is  merely  stressed  that  the 
basic  test  in  this  area  is  the  compati¬ 
bility  of  a  treaty's  provisions  with  a 
state  of  hostilities.  Under  this 
criterion,  it  does  not  appear  that  the 
Outer  Space  and  its  three  companion 
treaties  would  survive  the  test  and, 
thus,  would  be  suspended  between 
belligerents  during  a  period  of 
hostilities. 


CONCLUSION 

The  legal  regime  that  has  been 
created  for  outer  space  activities  and 
the  attempt  to  limit  certain  military 
applications  is  indeed  a  fragile  one. 

The  restrictions  during  peacetime  are 
very  few  and,  in  fact,  allow  for  a  broad 
use  of  space  for  non-aggressive  military 
purposes.  The  nebulous  nature  of  the 
restrictions  on  military  space  activities 
is  further  made  apparent  by  the  possible 
suspension  or  termination  of  such 
treaties  during  times  of  armed  conflict 
between  the  parties. 

However,  the  international  space  law 
community  should  regard  this  present 
state  of  the  legal  regime  of  outer  space 
as  a  challenge.  It  should  look  for 
areas  in  which  the  outer  space  regime 
could  be  stabilized  by  developing 
practical  and  workable  legal  principles 
in  areas  in  which  mutual  agreements  can 
be  realistically  obtained.  However, 
initially,  I  believe  it  is  important  to 
appreciate  the  limitations  that  inform 
this  area.  The  most  important  is  to 
acknowledge  that  disarmament  of  outer 
space,  while  a  noble  principle,  is 
directly  related  to  disarmament  on  the 
earth  and  therefore  should  not  be 
addressed  in  isolation.  The  second 
factor  to  understand  is  that  the  space 
powers  have  by  their  subsequent  conduct, 
provided  the  clearest  interpretation  of 
the  present  state  of  international  law 
vis  a  vis  the  use  of  outer  space  for 
military  purposes.  Once  these  premises 
are  acknowledged,  the  focus  can  then  be 
on  developing  additional  rules  and 
regulations  that  will  assist  in 
stabilizing  the  outer  space  regime  and 
limiting  the  possibility  that  outer  space 
will  be  utilized  for  hostile  purposes. 
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US  -  USSR  SPACE  LAUNCH  ACTIVITY 


Figure  1:  The  Soviet  Union  continues  its  high 
launch  rate  despite  improvements  in  satellite 
longevity. 

the  Soviet  Union  has  taken  the  lead  in  the  number 
of  space  missions  and  today  bests  the  U.S.  in 
launch  activity  by  a  ratio  of  5:1.  The  next  illus¬ 
tration  (Figure  2)  depicts  the  scope  of  the  Soviet 
space  threat. 

Numbers  alone,  however,  do  not  adequately 
reflect  the  differences  between  American  and  Soviet 
space  assets.  It  is  recognized  that  U.S.  satel¬ 
lites  are  generally  complex,  long-lived  and 
deployed  in  few  numbers  while  equivalent  Soviet 
networks  are  comprised  of  many  satellites  simple  in 
design  and  with  shorter  lifetimes.  For  example,  in 
1982  the  U.S.  placed  just  three  satellites  in 
orbits  characteristic  of  photo  reconnaissance 
missions  while  the  Soviets  launched  36  such  satel¬ 
lites.  Likewise  the  majority  of  Soviet  satellites 
are  placed  in  easy-to-reach  low  Earth  orbits,  while 
more  than  70%  of  American  satellites  reside  in  more 
difficult  12-  or  24-hour  orbits  (Figure  3). 
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Although  we  are  tempted  to  ascribe  these  dif¬ 
ferences  to  less  advanced  Soviet  technology,  there 
are  other  factors  also  at  work  here.  The  first  is 
economy.  By  mass-producing  relatively  simple 
satellites  and  launch  vehicles  the  Soviets  can 
avoid  the  astronomical  costs  associated  with  many 
U.S.  space  missions.  The  standardization  and 
commonalty  of  many  subsystems,  such  as  propulsion 
and  attitude  control,  further  reduces  expenditures 
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SOVIET  SPACE  THREAT 


Figure  2:  Soviet  space  systems  pose  a  direct 
threat  to  American  terrestrial  and  space  assets. 


Transportation  System  which  is  constrained  to 
operate  from  two  highly  vulnerable  sites  near  the 
coasts. 

The  remainder  of  this  presentation  will  high¬ 
light  individual  Soviet  space  programs  of  Interest 
to  this  audience.  By  far  the  largest  Soviet  space 
effort  is  devoted  to  photographic  reconnaissance. 

As  noted  earlier,  36  reconnaissance  spacecraft 
were  orbited  last  year.  Twenty-six  of  these 
remained  in  space  less  than  two  weeks.  The  remain¬ 
der  had  lifetimes  somewhat  longer,  usually  4  to  6 
weeks.  The  longer-lived  models  first  appeared  two 
years  after  the  Yom  Kippur  Middle  East  War  in  which 
the  Soviets  were  forced  to  launch  seven  photo 
satellites  in  three  and  a  half  weeks.  This  was 
necessary  because  the  intelligence  data  could  only 
be  analyzed  after  the  spacecraft  returned  to  Earth. 
The  newer  model  satellites  reportedly  carry  multi¬ 
ple  reentry  capsules  for  film  retrieval  on  demand. 


at  a  modest  sacrifice  in  capability. 

More  important,  however,  are  the  implications 
of  the  Soviet  deployment  philosophy  on  war-time 
survivability.  The  proliferation  of  Soviet  satel¬ 
lites  in  low  Earth  orbits  presents  any  enemy  with 
a  multitude  of  targets.  One-on-one  engagements 
by  conventional  interceptors  then  become  less 
attractive  both  from  a  weapon-to-target  cost  ratio 
and  from  a  timeliness  standpoint.  Furthermore, 
evidence  indicates  that,  as  a  result  of  the  large 
numbers  of  spacecraft  ana  launchers  produced,  the 
Soviets  maintain  a  stockpile  of  replacements  which 
are  available  for  launch  on  short  notice.  Thus,  if 
the  Soviets  were  to  lose  satellites  to  hostile 
action,  most  constellations  could  be  replenished 
in  short  order.  By  contrast  the  U.S.  is  ill- 
equipped  to  replace  any  satellite  quickly  enough 
to  support  most  postulated  terrestrial  conflicts. 

An  additional  advantage  to  the  Soviet  system 
is  its  reliance  on  launch  vehicles  of  tactical  or 
strategic  missile  origin  (eg.  SS-5  and  SS-9)  for 
many  satellite  launchings.  Conceivably  these 
satellites  could  be  orbited  from  non-historical 
launch  sites  in  times  of  crisis.  Meanwhile 
America  is  rapidly  coming  to  rely  on  the  Space 
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Interestingly,  the  next  illustration  (Figure 
4)  shows  that  as  the  average  lifetime  of  Soviet 
photographic  satellites  has  increased  during  the 
past  decade  the  number  of  missions  conducted  each 
year  has  remained  at  the  highest  levels.  Conse¬ 
quently,  the  cumulative  annual  mission  days 
continues  to  climb  and  the  simultaneous  operations 
of  two,  three  or  even  four  photo  satellites  is  not 
uncommon.  The  reluctance  to  reduce  the  annual 
launch  rate  implies  a  plentiful  supply  of  satel¬ 
lites  on  hand  should  they  be  needed. 


SOVIET  PHOTOGRAPHIC  PROGRAM 


w3MSi1 . Min 

Figure  4:  The  Soviet  photographic  reconnaissance 
program  is  the  largest  space  program  in  the  world. 


Figure  3t  Unlike  American  satellites ,  the  majority 
of  Soviet  satellites  reside  in  low  Earth  orbits. 


Soviet  photographic  spacecraft  are  often  used 
to  survey  areas  of  international  tension,  such  as 
the  Middle  East.  In  June  and  July  1982  three  of 
the  latest  generation  Soviet  satellites  maneuvered 
into  positions  highly  suggestive  of  a  monitoring 
mission  during  the  conflict  in  Lebanon.  Earlier 
this  year  Kosmos  1446  flew  a  highly  unusual  mission 
which  permitted  surveillance  of  the  Iran-Iraq 
battleground  during  its  entire  two  week  flight. 

In  another  field  of  space  technology  Soviet 
communications  satellites  are  spread  over  four 
major  constellations  and  number  as  many  as  30 
operational  spacecraft  (Figure  5).  In  the  low 
altitude  regime  are  two  systems  which  are  assumed 
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Figure  5:  Soviet  coamunications  satellites  are 
proliferated  in  widely  varying  orbits . 

to  fulfill  military  communications  requirements  in 
a  store-dump  mode.  The  first  system  consists  of 
modest  satellites  (estisMted  mass,  750  kg)  approxi¬ 
mately  800  km  high  in  three  orbital  planes  spaced 
120°  apart.  Command  centers  near  Moscow  or  else¬ 
where  in  the  Soviet  Union  can  transmit  to  the 
satellites  orders  which  are  later  replayed  when 
the  satellite  passes  over  far-flung  contingents. 

A  complementary  system  is  comprised  of  many 
small  satellites  (tAOkg)  orbited  eight  at  a  time 
to  altitudes  around  1470km  and  with  each  launch 
entering  the  same  nominal  orbital  plane.  Consider¬ 
ing  the  historical  lifetimes  of  Soviet  satellites, 
as  many  as  24  of  these  satellites  may  be  operation¬ 
al  slswltaneously.  Due  to  the  orbital  altitude  and 
inclination  of  the  satellites,  Moscow  should  enjoy 
almost  continuous  contact  with  the  constellation 
for  17  hours  a  day.  This  constellation  is  reminis¬ 
cent  of  the  U.S.  Initial  Defense  Comsninlcatlon 
Satellite  Program  (IDCSP)  which  although  utilizing 
much  higher  orbits  relied  on  26  operational  satel¬ 
lites  with  a  mass  of  45  kg  each. 

The  oldest  Soviet  communication  satellite 
network  is  the  Molnlya  system  which  still  handles 
a  large  share  of  Soviet  telecommunications .  Placed 
in  highly  elliptical,  12-hour  orbits,  Molnlya 
satellites  are  distributed  in  distinct  groups. 

Bight  Molnlya  1  satellites  are  placed  in  orbital 
planes  45°  apart  in  such  a  way  that  every  satel¬ 
lite  has  identical  groundtracks  and  are  separated 
from  one  another  in  time  by  3  hours.  Four  more 
advanced  Molnlya  3  satellites  circle  the  Earth  in 
orbital  planes  separated  by  90°  which  are  coinci¬ 
dent  with  four  of  the  Molnlya  1  planes.  Together 
the  Molnlya  satellites  provide  domestic  and  inter¬ 
national  telephone,  telegraph,  and  television 
services.  Molnlya  3  satellites  also  carry  hotline 
communications  between  Moscow  and  Washington. 

Future  Molnlya  satellites  may  carry  Volna  tran¬ 
sponders  for  maritime  and  aeronautical  users. 

The  Soviet  Union  was  slow  to  exploit  geo¬ 
stationary  orbits  for  geographical,  technological, 
and  economic  reasons.  Since  the  first  test  flight 


in  1974  the  Soviets  have  expanded  their  geostation¬ 
ary  communications  satellite  program  and  now  main¬ 
tain  seven  geostationary  positions.  Three  separate 
satellite  systems  are  now  operational:  Raduga  for 
domestic  and  international  teleconsnunication, 
Gorizont  for  support  of  the  INTERSPUTNIK  network, 
and  Ekran  for  television  transmissions  to  Siberia, 
the  Extreme  North,  and  the  Far  East. 


At  least  four  more  systems  are  due  to  be 
deployed  during  this  decade.  Luch,  Volna,  and  Gals 
all  appear  to  be  special  purpose  transponders  which 
will  be  attached  to  a  mother  satellite,  possibly  of 
a  Raduga  or  Gorizont  class.  A  Satellite  Data  Relay 
Network  (SDRN)  similar  to  the  American  TDRS  system 
is  also  in  the  development  stage. 


The  proliferation  and  diversity  of  Soviet 
communications  satellites  fit  in  well  with  the 
strong  Soviet  philosophy  of  survivable  command, 
control,  and  communications  (CJ).  The  more  central¬ 
ized  control  of  Soviet  satellites  also  implies  a 
greater  flexibility  of  communications  links  during 
periods  of  crisis  or  overt  space  hostilities. 


In  the  matter  of  navigation  satellites,  the 
Soviets  have  taken  a  slow,  low-risk  approach.  The 
firBt  experimental  navigation  satellite  was  launch¬ 
ed  in  1967  and  the  first  operational  network  was 
not  completed  until  1973.  The  interesting  feature 
of  these  satellites  is  their  remarkable  similarity 
to  the  American  Transit  program  whose  first  suc¬ 
cessful  launch  came  in  1960.  Not  only  are  the 
polar,  1000  km  high  orbits  of  the  Soviet  system 
similar  to  those  of  Transit,  but  the  doppler  tech¬ 
nique  is  virtually  identical  to  that  of  Transit 
even  down  to  the  transmission  frequencies.  The 
current  Soviet  network  is  comprised  of  ten  satel¬ 
lites  divided  into  two  constellations  (Figure  6). 
The  older  six-member  constellation  appears  to  be 
devoted  primarily  to  military  users  while  the  newer 
four-member  group  is  available  to  civilians,  par¬ 
ticularly  the  merchant  fleet.  Like  other  Soviet 
satellite  constellations,  the  capabilities  oi  their 
navigation  network  are  designed  to  degrade  grace¬ 
fully  with  the  loss  of  one  or  a  few  satellites.  On 
the  other  hand,  the  loss  of  one  or  two  Transit 
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Figure  6:  Navigation  satellites  are  playing  an 
expanding  role  in  Soviet  affairs. 
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satellites  (out  of  a  total  of  5)  would  be  more 
serious. 


A  new  generation  system  Is  now  under  develop- 
sent  in  the  Soviet  Union,  and  it  will  be  a  clone  of 
the  American  Navstar  Global  Positioning  System 
(GPS).  Dubbed  the  Global  Navigation  Satellite 
System  (GLONASS),  this  new  network  will  employ  the 
same  orbital  parameters  as  the  current  GPS  as  well 
as  almost  identical  transmission  frequencies.  The 
rationale  behind  copying  American  navigation  tech¬ 
niques  may  lie  in  the  potential  of  constructing 
receivers  which  operate  on  either  the  American  or 
Soviet  system.  Since  Transit  and  portions  of  GPS 
are  available  to  civilians,  the  Soviets  could  use 
these  satellites  for  non-critical  missions. 

Potentially,  some  of  the  most  valuable  Soviet 
satellites  may  belong  to  their  ocean  surveillance 
program.  Regrettably  these  satellites  usually 
only  receive  media  attention  when  one  of  the 
nuclear-powered  radar  models  malfunctions  and  falls 
back  to  Earth.  Even  then  focus  is  not  placed  on 
their  missions  or  capabilities,  but  instead  of 
generating  headlines  about  radioactive  debris  from 
space.  By  the  end  of  1982  two  dozen  spacecraft 
had  been  orbited  in  this  radar  ocean  surveillance 
program  since  the  first  one  appeared  in  late  1967. 
The  program  entered  a  new  operational  phase  in  1974 
when  pairs  of  satellites  (usually  coplanar)  began 
patrolling  the  world's  oceans,  searching  for 
foreign  naval  vessels.  Four  such  satellites  were 
orbited  in  1982.  The  third  of  these  was  the 
infasKius  Kosmos  1402,  parts  of  which  reentered  the 
atmosphere  in  January  and  February  of  this  year. 


Also  in  1974  a  complementary  program  of 
passive  ELINT  ocean  surveillance  satellites  was 
Inaugurated.  These  satellites  fly  in  slightly 
higher  orbits,  often  in  pairs,  and  are  phased  with 
satellites  of  the  radar  variety  (Figure  7).  Since 
1980  operations  of  both  types  of  satellites  have 
greatly  expanded. 


SOVIET  OCEAN  SURVEILLANCE  CONSTELLATIONS 


Figure  7t  Ocean  surveillance  satellites  are  perhaps 
some  of  the  USSR's  most  valuable  space  resources . 

Reportedly,  these  satellites  are  capable  of 
locating,  tracking,  and  identifying  enemy  ships 
for  targeting  purposes.  Replacements  for  malfunc¬ 
tioning  satellites  have  been  observed  within  24  or 


48  hours  after  mission  termination.  Replenishments 
are  also  sometimes  timed  to  coincide  with  major 
Western  naval  exercises.  For  example,  by  early 
May  1983  all  Soviet  ocean  surveillance  satellites 
were  non-operational.  However,  with  large  NATO 
sea  games  (Distant  Drum  '83)  scheduled  for  16-27 
May,  the  first  passive  ELINT  ocean  surveillance 
satellite  of  the  year  was  orbited  on  7  May. 

Another  class  of  strateglcly  important  satel¬ 
lites  are  those  on  missile  early  warning  missions. 
Placed  in  orbits  similar  to  Molnlya  satellites,  the 
early  warning  spacecraft  form  a  constellation 
capable  of  nearly  world-wide  surveillance.  Again 
beginning  in  1980,  this  network  experienced  a 
dramatic  increase  in  Soviet  attention  and  capabil¬ 
ities.  The  limited  three-member  network  has  been 
expanded  to  the  full  nine-member  complement  and 
the  annual  launch  rate  has  more  than  doubled 
(Figure  8).  In  1981-82  the  entire  constellation 
was  shifted  to  provide  better  coverage  of  the 
United  States.  With  perigees  deep  in  the  southern 
hemisphere,  Soviet  early  warning  satellites  pose 
difficult  targets  for  most  anti-satellite  systems. 

SOVIET  EARLY  WARNING  NETWORK 


Figure  8:  Since  late  1980  the  Soviet  early  warning 
netwoik  has  been  expanded  from  3  to  9  satellites. 


The  most  significant  development  in  the  Soviet 
space  program  thus  far  in  this  decade  has  been  the 


Figure  9t  The  Soviet  Union  has  twice  space-tested 
a  subscale  model  of  a  reuseable  shuttle  craft. 
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testing  of  a  reuseable  space  plane.  Flown  once  In 
1982  and  once  earlier  this  year  as  a  subscale 
aodel,  the  new  spacecraft  closely  resembles  the  old 
NASA  HL-10  lifting  body.  This  picture  (Figure  9) 
was  taken  by  the  Royal  Australian  Air  Force  during 
the  recovery  of  Kosmos  1445  in  the  Indian  Ocean  on 
16  March  this  year.  The  Department  of  Defense 
(DOD)  estimates  that  operational,  manned  flights 
could  come  by  the  end  of  this  decade.  The  space 
plane  will  probably  be  used  as  a  shuttle  craft  for 
low  altitude  space  stations,  but  could  also  play  a 
reconnaissance  role  when  necessary.  A  larger 
shuttle  craft  roughly  equivalent  to  American  STS 
shuttles  is  also  apparently  under  development 
although  the  first  teat  flight  might  be  two  or 
more  years  away. 

Finally,  we  come  to  the  only  offensive  space 
weapon  system  currently  operational  in  the  world: 
the  Soviet  anti-satellite  (ASAT)  system.  Shown 
here  in  this  DOD  drawing  (Figure  10),  the  Soviet 
ASAT  vehicle  is  an  orbital  spacecraft  which 
approaches  close  to  its  target  and  fires  a  conven¬ 
tional  warhead.  Between  1968  and  1982  the  Soviets 
have  tested  this  system  twenty  times.  Successful 
Intercepts  have  been  made  at  altitudes  as  low  as 
150  km  and  as  high  as  1700  km.  Times  of  flight 
vary  from  1%  to  3%  hours. 


SOVIET  ANTI-SATELLITE  TEST:  3  DECEMBER  1971 
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Figure  ill  Satellites  as  low  as  150  km  have  been 
intercepted  by  Soviet  ASATs. 

tracking  of  the  target  satellite.  However,  to  date 
all  such  tests  (a  total  of  6)  appear  to  have  been 
failures.  The  last  successful  ASAT  test  was  in 
March  1981  when  an  older,  radar-guided  ASAT  was  used. 
If  both  types  of  ASAT  become  operational  American 
countermeasures  may  have  to  be  more  versatile. 

SOVIET  ANTI-SATELLITE  TEST:  14  MARCH  1981 
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Figure  lOi  The  Soviet  anti-satellite  vehicle 
carries  a  conventional  warhead. 

The  next  illustration  (Figure  11)  depicts  the 
intercept  of  a  low  altitude  (230  km)  target.  The 
Interceptor  is  launched  into  a  longer,  elliptical 
orbit  and  swoops  down  on  the  target  from  above. 

An  alternate  profile  to  attack  higher  satellites  is 
shown  here  (Figure  12).  The  target  is  in  a  Transit- 
type  orbit  (l.e.  1000km,  circular).  The  ASAT  space¬ 
craft  again  enters  an  elliptical  orbit,  but  this 
time  the  intercept  is  made  from  below  at  apogee. 
Although  these  two  actual  space  tests  required  the 
Interceptor  to  complete  two  revolutions  of  the 
Earth,  successful  tests  have  been  sude  after  only  a 
single  revolution.  Consequently,  warning  time  can 
be  significantly  reduced,  placing  a  greater  demand 
on  the  employment  of  countermeasures  by  the  target. 

The  majority  of  tests  during  the  past  few 
years  have  concentrated  on  the  perfection  of  a  new 
optical  or  IR  sensor  for  acquisition  and  end-game 
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Figure  12 i  Soviet  ASATs  can  probably  reach 
targets  as  high  as  2000  km. 

Since  the  majority  of  American  satellites  are 
in  high  altitude  orbits,  they  are  now  beyond  the 
reach  of  the  Soviet  ASAT.  In  1981  DOD  speculated 
that  the  Soviets  were  then  working  on  a  new  system 
which  could  attack  synchronous  and  semi-synchronous 
satellites.  This  could  be  accomplished  by  mating 
the  current  ASAT  with  a  larger  launch  vehicle  (eg. 
SL-12)  or  by  designing  an  entirely  new,  multi-shot 
ASAT.  Meanwhile  some  highly  valuable,  low  altitude 
American  satellites  remain  vulnerable  to  Soviet 
attack. 

The  combination  of  proliferated  support  satel¬ 
lites  and  their  ready  replacements  with  an  anti- 
satellite  capability  presently  gives  the  Soviets  a 
war- fighting  edge  should  hostilities  leap  from  the 
surface  of  the  Earth  into  outer  space.  Failure  of 
the  United  States  to  address  this  disparity  of 
space  forces  will  have  far-reaching  consequences 
in  both  global  military  and  political  affairs. 
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ABSTRACT 

V 

This  paper  describes  a  distributed  database 
model  that  simulates  database  utilization  in  the 
SPADOC  data  processing  environment.  The  model  is 
table  driven  such  that  database  access  require¬ 
ments,  file  locations,  and  other  information 
necessary  for  defining  the  database  environment 
are  set  up  internally  in  several  tables.  Each 
operation  for  the  SPADOC  mission  is  defined  and 
represented  by  a  transaction  flow  diagram  (TFD) 
and  a  sequence  of  TFDs  representing  a  misrsion  is 
input  to  the  model.  The  mode  l^executes^input 
TFDS  by  looking  up  tables  that  specify  their  data 
file  access  requirements.  While  executing  TFDs, 
the  history  of  database  usage  is  logged  and 
various  statistics  are  gathered.  The  performance 
data  are  used  to  measure  database  access  overhead, 
characterize  database  workload,  and  fine-tune  per¬ 
formance  by  reallocating  files. 


databases  have  been  implemented.  Development  of 
distributed  databases  involves  a  number  of  problems 
that  defy  simple  solutions  (1).  Furthermore,  in 
most  cases,  database  performance  is  measured  by 
benchmarking  rather  than  simulation  (2,  3).  How¬ 
ever,  benchmarking  must  have  available  a  database 
and  workload  that  are  representative  of  the  appli¬ 
cation  environment.  Simulation  of  a  distributed 
database  is  often  done  analytically  (A,  5),  but 
analytical  simulation  lacks  fidelity  of  database 
representation  and  is  usually  used  for  modeling  a 
top  level  structure  of  database  systems. 

In  the  sections  that  follow,  the  SPADOC  opera¬ 
tional  environment  and  database  design  are  sum¬ 
marized.  The  database  usage  simulation  model 
organization  and  simulation  method  are  presented 
and  example  results  are  analyzed. 

SPADOC  OPERATIONAL  ENVIRONMENT 


The  model  has  been  implemented  in  Fortran  on 
the  VAX  11/780  and  has  been  used  for  both  mea¬ 
suring  a  given  database  and  analyzing  sensitivity 
to  design  changes.  It  has  proven  to  be  an  effec¬ 
tive  tool  for  measuring  and  analyzing  design 
effectiveness  of  distributed  databases.  _ 


INTRODUCTION 


This  paper  describes  a  simulation  and  analysis 
method  that  was  used  to  model  the  distributed  data¬ 
base  usage  pattern  of  the  Space  Defense  Operation 
Center  (SPADOC)  which  is  to  be  deployed  by  NORAD. 
The  simulation  deals  primarily  with  file  access 
behavior  of  a  subject  system  and  does  not  simulate 
details  of  database  management  functions  such  as 
query  processing  and  database  methods.  It  repre¬ 
sents  or  assumes  no  specific  database  management 
system,  and  hence,  no  provisions  are  made  for  such 
complex  design  issues  as  concurrency  control, 
replicated  file  update,  failure  recovery,  and  the 
like,  which  are  subjects  of  current  intensive  re¬ 
search.  Although  the  simulation  model  was  devel¬ 
oped  for  a  special  case  of  distributed  databases, 
it  is  applicable  to  a  wide  variety  of  distributed 
database  designs. 

The  literature  on  distributed  database  simula¬ 
tion  is  scarce,  if  any,  possibly  because  most 
simulation  experiments  are  application-specific 
and  because  only  a  small  number  of  distributed 


SPADOC  is  a  command  and  control  system  for  the 
Air  Force/NORAD  space  defense  missions.  The 
SPADOC  will  catalog  orbital  characteristics  of  all 
space  traffic,  maintain  space  asset  status,  access 
the  space  situations  and  issue  warnings  of  hostile 
actions,  protect  space  assets  from  the  hostile 
actions,  and  if  necessary,  coordinate  negation 
activities  of  hostile  threats  to  space  assets. 
SPADOC  is  an  evolutionary  system  and  will  be 
developed  over  the  next  several  years  to  meet 
future  Space  Command  mission  needs. 

The  current  design  for  the  SPADOC  baseline 
hardware  architecture  consists  of  three  IBM  3083s 
connected  by  a  high-speed  bus:  two  operationally 
active  and  one  a  backup  (Figure  1).  Although 
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physically  similar,  all  three  computers  have 
distinct  functions  and  interact  with  each  other 
over  the  high  speed  bus.  The  Communications  and 
Display  (C&D)  computer  processes  operator  commands 
and  requests,  and  provides  sophisticated  display 
output  (e.g.,  graphics)  and  serves  as  the  communi¬ 
cation  processor  to  interface  the  automatic  message 
handling  system  software.  The  Host  computer  exe¬ 
cutes  all  computationally  complex  application 
programs;  i.e.,  programs  necessary  for  satellite 
tracking  and  space  situation  assessment.  The 
backup  processor  is  normally  used  for  exercise  and 
training,  but  in  case  of  failure,  can  be  switched 
on-line  to  replace  a  failed  operational  computer. 
All  three  computers  contain  network  database 
management  systems  (DBMSs).  This  hardware  redun¬ 
dancy  improves  significantly  the  availability/ 
reliability  of  the  distributed  system  (6).  Redun¬ 
dancy  is  also  provided  for  the  disk  storage  so 
that  critical  and  frequently  used  files  may  be 
duplicated. 

The  SPADOC  data  processing  is  characterized 
by  heavy  interactions  between  the  operator  and  the 
database  system  and  between  application  programs 
and  the  database  system.  It  will  eventually 
evolve  such  that  most  of  the  operator  intervention 
will  be  automated  so  that  manual  operations  are 
minimized.  Our  analysis  shows  that  approximately 
90  percent  of  all  accesses  to  the  database  are  due 
to  applications  programs,  suggesting  that  the 
database  efficiency  is  crucial  to  the  overall 
system  performance.  This  necessitated  a  rigorous 
analysis  of  the  database  performance  and  access 
patterns . 

SPADOC  DATABASE  DESIGN 

The  SPADOC  database  is  partitioned  without 
replication  between  the  host  and  C&D  (Figure  1) 
eliminating  the  need  for  updating  multiple  copies. 
Each  processor  has  a  complete  database  manager  and 
when  necessary,  is  able  to  access  the  other  data¬ 
base  partition  transparent  to  the  requester 
through  the  connecting  bus.  Files  are  allocated 
such  that  a  processor  accesses  the  local  database 
almost  exclusively.  This  minimizes  communication 
overhead  incurred  in  database  access.  Database 
partitioning  has  several  advantages  with  respect 
to  performance,  growth  potential  and  reliability; 
these  include: 

1.  Data  access  time  is  reduced  significantly 
because  each  partition  is  physically  much 
smaller  than  the  total  database; 

2.  Throughput  of  database  processing  is  increas¬ 
ed  because  database  accesses  may  be  processed 
concurrently  at  multiple  processors; 

3.  Potential  for  database  access  contention  is 
reduced  because  access  is  made  at  different 
partitions ; 

4.  Potential  for  creating  a  system  bottleneck 
to  request  queue  buildup  is  minimized  by 

,  database  load  balancing; 

5.  Failure  of  one  computer  results  in  loss  of 


6.  Fault  recovery  is  done  much  faster  because 

each  partition  is  physically  smaller  and  the 
number  of  updates  journaled  during  failure 
should  be  smaller; 


7.  Additional  processors  and  database  partitions 
may  be  added  to  accommodate  growth  without 
disturbing  the  existing  ones. 

To  be  sure,  database  partitioning  has  some 
drawbacks.  Most  notably,  the  design  complexity 
requires  careful  analysis  for  file  allocation 
(7).  If  file  allocation  was  done  improperly, 
the  database  performance  degrades  rapidly. 

SIMULATOR  DESCRIPTION 


The  simulator  is  a  table-driven  model  that 
represents  the  database  environment  and  simulates 
database  usage  of  a  SPADOC  mission.  A  SPADOC 
mission  is  represented  by  a  sequence  of  transaction 
flows  called  TFDS  (Transaction  F  Diagrams).  A 
TFD  is  a  control  flow  diagram  r'  '-onsists  of 
flows  of  control,  operator  trar  cions,  program 

module  executions  and  files  act  'd  (Figure  2). 


Figure  2.  Example  TFD 


A  TFD  defines  an  operation  such  as  threat  assessment 
and  verification,  vulnerability  to  nuclear  effects, 
cluster  analysis,  etc.  A  mission  is  generated  by 
the  Scenario  Generator  which  is  an  interactive 
tool  for  the  design,  simulation  and  analysis  of 
space  defense  scenarios.  For  a  user  supplied 
description  of  the  space  engagements  to  be  modeled, 
the  Scenario  Generator  generates  a  timeline  of 
mission  events  including  launches,  manuevers,  inter¬ 
cepts,  etc.,  which  is  used  to  activate  the  SPADOC 
TFDs  and  in  turn  drive  the  database  model  as  well 
as  the  data  processing  simulation  model. 

The  database  usage  simulator  consists  basical¬ 
ly  of  three  units:  initialization  unit,  mission 
execution  unit,  and  report  generation  unit.  The 
initialization  unit  prepares  all  the  data  and 
tables  necessary  for  the  simulation.  In  particular, 
it  constructs  three  tables  that  represent  the  file 
access  patterns  of  TFDs  (Figure  3).  A  mission 
tape  generated  by  the  Scenario  Generator  is  input 
to  the  database  simulator.  All  TFDs  to  be  executed 
are  represented  by  a  number  which  is  used  as  an 
index  to  a  table,  TFDKEY,  that  contains  indices  to 
another  table,  INVOKE.  A  pair  of  consecutive 


tfdkey 


INVOKE 


TFDA 


Figure  3.  Table  Structure  for  TFD  File 
Access  Representation 

elements  in  TFDKEY  specify  the  operation  boxes 
within  one  TFD.  A  pair  of  consecutive  elements  in 
INVOKE  specify  a  list  of  files  to  be  accessed  by  an 
operation  box.  The  contents  of  the  three  tables 
for  the  example  TFD  are  shown  in  Figure  3.  A 
negative  file  number  in  TFDFA  denotes  write  access 
to  the  file. 

The  report  generator  unit  receives  data  pro¬ 
vided  by  the  mission  execution  unit  and  generates 
comprehensive  reports  that  summarize  the  result  of 
simulation. 

The  mission  execution  unit  performs  the  simu¬ 
lation  proper.  During  simulation,  it  collects 
data  and  generates  performance  statistics.  Logic¬ 
ally,  it  consists  of  four  program  modules: 

1.  File  Access  Simulator.  By  table  look-ups, 
this  executes  database  accesses  for  TFDs , 
determines  types  of  access  such  as  local/ 
remote  and  read/write,  and  gathers  statistics 
on  file  usage.  Some  typical  statistics  in¬ 
clude  a  number  of  local  read  and  local  write 
accesses,  remote  read  and  remote  write 
accesses,  sources  of  access,  etc. 

2.  Buffer  Manager.  For  each  file  access,  this 
determines  whether  the  requested  file  is  in 
the  work  area  (i.e.,  buffer)  and  counts  the 
number  of  time  the  files  are  found  in  the 
work  area.  This  number  is  used  to  compute 
the  hit/miss  ratio  and  the  amount  of  overhead 
necessary  for  disk  storage  access. 

3.  File  Access  Correlator.  This  analyzes  the 
situation  where  two  or  more  files  are 
accessed.  In  many  instances,  whenever  one 
file  is  accessed,  another  file  is  also 
accessed.  These  files  are  correlated  so 
that  some  optimization  in  file  structure 
and  file  allocation  may  be  made. 

4.  Histogram  Generator.  This  generates  a  histo¬ 
gram  of  database  workload  during  an  entire 
mission.  This  histogram  may  be  constructed 
at  any  pre-specif ied  interval.  This  was  used 
to  identify  a  peak  load  period  so  that  more 
detailed  performance  analysis  may  be  done  for 
this  period. 

Figure  4  shows  the  structure  and  inter¬ 
relation  of  the  software  components  discussed 
above.  The  File  Access  Correlator  and  Histogram 
Generator  may  be  switched  on  or  off  by  setting 


appropriate  flags.  The  program  is  written  in 
Fortran  77  on  the  VAX  11/780  and  is  relatively 
small  (approximately  600  source  lines)  and 
modu lar . 


START 


END 

Figure  4.  Structure  of  the  Database  Usage 

Simulator 

ANALYSIS  OF  RESULTS 

Examples  of  the  simulator  outputs  are  illus¬ 
trated  in  Figures  5-8.  Figure  5  shows  summary 
results  of  file  usage  during  a  hypothetical  mission 
which  spanned  67  hours,  27  minutes.  During  this 
mission  period,  a  total  of  4908  file  accesses  were 
made,  of  which  4137  (84  percent)  were  read  access 
and  771  (16  percent)  write  access.  The  frequencies 
of  access  to  the  host  and  C4.D  databases  as  well  as 
the  sources  of  the  accesses  are  also  shown.  Occa¬ 
sionally,  a  computer  (or  the  operator'  needs  access 
to  data  located  at  the  other  computer  requiring 
request  message  transmission  across  the  connecting 
bus.  This  database  access  across  the  bus  is  called  a 
remote  access.  A  remote  access  is  extremely  time 
and  resource  consuming  so  that  it  should  be  mini¬ 
mized  where  possible  by  strategically  allocating 
the  files  at  either  the  host  or  C&D.  In  this 
example,  slightly  over  10  percent  of  all  accesses 
are  remotely  made.  To  minimize  the  remote  access 
rate,  the  access  profile  of  each  individual  file 
must  be  analyzed  so  that  a  better  file  allocation 
may  be  determined  (7-9).  Figure  6  shows  individual 
file  usage  profiles  which  list  sources  and  types 
of  access  and  their  frequencies.  Of  particular 
interest  for  allocation  are  columns  for  remote  use 
(read)  and  remote  set  (write).  If  a  file  is  more 
frequently  remote-accessed  than  local-accessed,  it 
is  a  good  candidate  for  reallocation.  In  addition, 
prioritization  of  read'write  access  types  can  also 
factor  into  tuning  the  database  allocation,  e.g., 
often  read  accesses  are  considered  more  critical 
than  write  accesses. 


105 


DB  Work  Area  (Buffer)  Size  for  Host: 
DB  Work  Area  (Buffer)  Size  for  C&D: 

Total  Number  of  TFD's  Executed 
Elapsed  Mission  Time 

Total  Number  *'i  File  Accesses 
Number  of  Use  (Head) 

Number  ol  Set  (Write) 

Number  of  Accesses  to  Host  DB 
From  Host 

From  CbD  * 

From  Operator 
Humber  of  Hits  at  Host 
Use  *  l L 10  Set 

Number  of  Accesses  to  CkD  DB 
From  Host 
From  C6D 
From  Operator 
Number  of  Hits  at  C&D 

Use  a  1884  Set  * 


Total  Number  of  Remote  Accesses 
Remote  Accesses  to  Host 
Remote  Acc  esses  S  f>  CAD 


20  Fi  les 
20  Files 


4  18 

* 

67  Hour 

s  7  7 

n  l  Sec 

4908 

a 

41  3? 

f 84.29 

Percent ) 

- 

7  71 

(15.71 

Percent ) 

2  34  7 

(47.82 

Percent ) 

a 

20  7  3 

(88.  n 

Percent ) 

« 

46 

(  4.09 

Percent ) 

. 

178 

(  7.58 

Percent ) 

= 

1314 

(55.9‘j 

Percent ) 

* 

204 

u 

2561 

(57.18 

Percent ) 

a 

2  lb 

(  9.7  2 

Percent ) 

« 

2179 

(85.08 

Percent) 

a 

116 

(  5.70 

Percent ) 

• 

2220 

(86.68 

Percent ) 

3)6 

510 

(10.39 

Percent ) 

a 

2  74 

(  5.58 

Percent ) 

> 

2  36 

(  4.81 

Pei  cent ) 

DATA  RASE  WUttKLoAP  01  **TR  I  ROT  ION 
li«nu>  I  lull  Sour i r 


_{,«.•  _  t  _AP _ A » 


Mo»t  PaU  «4|V  CAD  U*ta  BjlKf 
1.01  1  Rt-mUt-  Lot  •  1  Krmot*  Lot*  l  Kr^»t  •• 

:  ..  t  m  »  Ua»  H»r  Sift  _ 


Summary  of  File  Usage  Statistics 


FILE  ACCESS  PROFILE 
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File  access  correlation  expressed  in  frequency 
of  concurrent  access  to  file  clusters  is  shown  in 
Figure  8.  In  the  example,  files  121  and  106,  116 
and  149  are  accessed  together  13  times.  Correlation 
is  useful  for  both  file  allocation  and  physical 
organization  and  indexing  of  files. 


Number  ol  File*  at  Host  »  7b 
Number  of  Files  at  CAD  •  91 


Figure  6.  Access  Profile  of  Individual  Files 


Figure  7  illustrates  the  database  workload  characteri¬ 
zation  over  a  mission  period.  In  this  example, 
all  database  accesses  in  five  minute  periods  are 
distinguished  for  the  host  database  and  C&D  data¬ 
base  accesses  as  well  as  local/remote  read  and 
local/remote  write.  This  data  is  useful  for  identi¬ 
fying  a  five  minute  peak  load  period  and  observing 
the  distribution  of  workload  between  the  host  and 
C&D  during  this  period.  If  one  of  the  computers 
is  overloaded,  for  example,  and  could  not  meet  the 
performance  (e.g.,  response  time)  requirement  during 
this  critical  peak  load  period,  load  balancing  based 
on  these  data  can  be  performed. 
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Figure  8.  File  Acceaa  Correlation 
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CONCLUSIONS  AND  FUTURE  EXTENSIONS 

A  simple,  yet  effective  distributed  database 
simulation  model  is  presented.  Generally,  simula¬ 
tion  of  a  fully  distributed  database  is  extremely 
difficult  because  of  a  number  of  unknown  factors 
that  exist  in  the  design.  The  SPADOC  database, 
however,  is  distributed  without  replication  bet  -< n 
two  processors,  which  simplified  considerably  many 
of  the  problems  associated  with  the  design  and  made 
the  simulation  more  tractable.  Although  developed 
for  a  specific  database,  the  simulation  model  and 
method  are  applicable  to  more  general,  more  com¬ 
plex  distributed  databases. 

The  simulation  model  is  being  refined  to  imple¬ 
ment  simulation  of  database  access  contention  so 
that  overhead  in  concurrency  control  may  be  cal¬ 
culated.  Database  access  overhead  that  includes 
disk  storage  access  is  being  incorporated.  However, 
overhead  calculation  is  to  a  great  extent  dependent 
on  a  particular  database  management  policy  and 
access  time  of  particular  disk  storage  devices. 

The  simulation  must  be  flexible  enough  to  model  a 
variety  of  database  managers  so  that  comparative 
database  performance  analysis  may  be  made. 

The  database  simulation  model  has  been  used 
extensively  as  a  design  tool  for  the  SPADOC  data¬ 
base  design  and  has  proven  to  be  very  valuable.  It 
was  used  to  analyze  sensitivity  to  database  design 
and  operational  environment  changes.  As  demon¬ 
strated  by  the  examples,  the  database  usage  data 
generated  by  the  simulator  provided  the  basis  for 
effective  database  design  performance  measurement 
and  validation. 
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ABSTRACT 

V 

This  paper  examines  the  tradeoffs 
in  orbital  parameters  and  the  geometric 
relationships  involved  in  satellite 
surveillance  of  ocean  areas.  For  illus¬ 
trative  purposes  synthetic  aperture 
radar  (SAR)  has  been  used  as  the  sensor, 
hence  some  discussion  of  the  sensor 
characteristics  is  included  as  well  as 
orbital  considerations,  power  requirem¬ 
ents  and  data  processing.  Assuming  that 
a  target  is  detectable  with  SAR,  this 
paper  concludes  that  a  single  SAR  satel¬ 
lite  with  optimum  orbital  parameters 
provides  a  high  probability  of  detection 
of  a  target  transitting  in  a  given 
coverage  area.  ^ 


PART  I  -  INTRODUCTION 
Background 

1.  Submarine  detection  since  the 
World  War  II  has  been  largely  dependent 
on  acoustic  means.  While  passive  devices 
have  increasingly  replaced  active  sonar 
both  are  inherently  limited  by  the 
vagaries  of  sound  propagation  in  water. 

The  search  for  reliable  large  area,  non¬ 
acoustic  means  of  detection  has  been 
unsuccessful  but  attempts  continue. 

2.  The  effects  such  a  sensor, 
mounted  on  a  satellite,  could  have  on 
maritime  operations  would  be  dramatic. 
They  prompted  Admiral  Rickover,  in  Feb  82, 
to  state  "The  future  naval  war  is  going 

to  be  decided  under  the  polar  ice  -  the 
only  place  submarines  will  be  able  to 
hide  from  satellites." 

Aim 

3.  The  aim  of  this  paper  is  to 
examine  the  tradeoffs  in  orbital 
parameters  and  the  geometric 


relationships  involved  in  satellite 
surveillance  of  submarines,  given  that  a 
suitable  sensor  were  available. 

PART  II  -  DISCUSSION 

Approach 

4.  Synthetic  aperture  radar  (SAR) 
will  be  used  as  the  illustrative  sensor, 
hence  a  discussion  of  its  characteristics 
is  included.  These  characteristics  are 
compared  to  orbital  parameters  to  derive 
general  guidelines  for  orbit  construction. 
An  initial  orbit  is  developed  and  its 
coverage,  advantages  and  disadvantages 
are  discussed.  Next  communications,  data 
processing  and  power  considerations  for 

a  satellite-borne  SAR  are  dealt  with. 
Detection  probabilities  of  this  orbit 
against  a  specific  submarine  mission  are 
evaluated,  first  using  one  satellite,  then 
a  two  satellite  constellation.  Based  on 
this  orbit’s  disadvantages,  an  improved 
one  is  constructed  and  evaluated  in  the 
same  way  as  the  first.  Lastly  general 
conclusions  about  orbital  and  operational 
requirements  are  formulated. 

Synthetic  Aperture  Radar 

5.  A  conventional  all-around  search 
radar  scans  in  azimuth  by  a  continuous 
360  degree  rotation  of  the  antenna.  It's 
resolution  in  range  is  dependent  on  the 
duration  of  the  transmitted  pulse  and  is 
independent  of  range.  In  azimuth, 
resolution  is  dependent  on  beamwidth.  For 
a  given  frequency  the  larger  the  antenna 
the  narrower  the  beamwidth.  Since  the 
beam  gets  wider  with  increasing  range  the 
resolution  decreases  with  range  ie  at 
twice  the  range  the  azimuth  resolution  is 
only  half  as  good. 

6.  Operation.  In  a  Synthetic  aperture 
rad?r  the  antenna  is  fixed  and  points  off 
the  direction  of  motion,  most  often  by 

90  degrees.  The  azimuthal  extent  of  the 
scene  viewed  by  the  radar  is  established 
by  the  movement  of  the  radar  platform 
carrying  the  radar  footprint  over  some 


particular  distance  by  collating  together 
the  successive  radar  returns  received 
during  the  time  period  the  radar  platform 
was  carried  over  that  distance.  As  in  a 
conventional  radar  a  SAR  transmits  a 
microwave  pulse  which  strikes  the  area 
of  interest  and  returns  to  the  receiver. 
Range  is  determined  in  the  normal  way 
by  the  time  it  takes  the  pulse  to  travel 
to  and  from  the  target.  In  a  SAR 
however  the  frequency  spectrum  of  the 
returned  pulse  is  also  determined.  By 
comparing  this  to  the  frequency  of  the 
transmitted  pulse  the  changes  in 
frequency  due  to  the  doppler  caused  by 
satellite  notion  are  known.  As  will  be 
shown,  in  effect  this  causes  the 
azimuthal  resolution  to  be  a  function 
of  the  .data  processing  carried 


7.  In  fig  I  the  footprint  of  the 

radar  beam  for  a  single  pulse  is  shown. 
The  concentric  rings  centered  on  the 
satellite  sub-orbital  point  (position  on 
the  earth  directly  beneath  the  satellite) 
are  lines  of  equal  range.  The  hyperbolas 
show  lines  of  equal  doppler  shift.  Thus 
a  given  range  and  a  given  doppler  shift 
will  uniquely  define  a  point  on  the 
earth's  surface.  However  from  a  single 
radar  pulse  we  cannot  determine  how  much 
of  the  energy  in  the  returned  signal  is 
due  to  that  point  alone.  If  we  illumin¬ 
ate  the  point  with  a  succession  of  pulses 
(several  thousand)  over  several  seconds 
from  a  transmitter  moving  at  high  speed 
it  is  possible  to  extract  that  inform¬ 
ation  by  evaluating  the  way  in  which  the 
range  and  the  doppler  shifts  vary  over 
the  time  interval  chosen. 

FIG  I  -  SAR  OPERATION 
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8.  Resolution-.  Extensive  data 

processing  of  the  "film  strip"  raw  data 
from  a  synthetic  aperture  radar  produces 
an  image  resembling  a  strip  photograph 


depicting  an  area  up  to  several  hundred 
nautical  miles  wide.  The  resolution  in 
range  (ie,  across  the  width  of  the  strip) 
is  dependent  on  the  transmitted  pulse 
duration  as  in  a  conventional  radar.  The 
resolution  in  azimuth  (ie  along  the 
length  of  the  strip)  is,  in  practice, 
dependent  on  how  small  a  doppler  shift 
we  can  detect  and  is  independent  of  the 
range  to  the  target.  It  is  therefore  a 
function  of  the  duration  of  the  period 
over  which  the  raw  data  is  integrated  and 
thus  to  the  power  of  the  processing 
applied  to  the  data. 

9.  Since  it  operates  in  the  microwave 
region  SAR  is,  unlike  a  camera,  essential¬ 
ly  independent  of  weather  and  lighting 
conditions.  Being  a  line-of-sight  device 
the  higher  it  is  above  the  ground  the 
greater  area  it  has  in  view. 

10.  SAR  is  inherently  useful  only 
against  stationary  or  slow  moving  targets 
since  its  resolution  depends  on  the  use 
of  the  frequency  change  (doppler)  of  the 
returned  signals,  and  the  data  processing 
makes  the  assumption  that  the  doppler  is 
contributed  (caused)  only  by  the  motion 
of  the  satellite,  and  by  the  rotation  of 
the  earth,  not  by  target  movement. 

11.  Past  Use.  Synthetic  aperture  radar 
has  been  used  for  a  number  of  years 
mounted  on  aircraft  but  only  recently  have 
the  obvious  potential  advantages  of 
placing  it  at  a  much  higher  altitude  (i.e. 
on  a  satellite)  been  utilized.  Thus  far 
its  use  on  satellites  has  only  been 
experimental  (SEASAT  in  1978  and  Shuttle  2 
in  1981)  but  there  are  several  projects 
ongoing  in  Canada,  Europe  and  Japan  to 
use  it  commercially  for  ice  reconnaissance 
surveillance  of  crop  conditions  and  other 
resource  related  activities.  These 
projects  have  anticipated  launches  in  the 
period  1988-1990. 

Orbital  Considerations 

12.  None  of  the  above  mentioned 
projects  are  optimized  for  open  ocean 
coverage.  As  a  result  their  coverage 
tends  to  overlap  or  leave  areas  un-looked 
at .  The  coverage  pattern  of  the  proposed 
Canadian  project  (called  RadarSat)  is 
shown  in  Fig  2  as  an  example  of  this.  The 
reason  for  this  uneven  coverage  is  that 
the  ascending  and  descending  swaths  cross 
at  a  significant  angle. 


FIG  2 


RADARSAT  COVERAGE  PATTERN 


13.  Inclination.  To  minimize  the 
amount  of  duplicated  coverage  an  orbit 
whose  coverage  swath  runs  as  near  as 
possible  along  a  meridian  (i.e.  N-S)  is 
required.  For  the  altitude  of  interest 
(550-650  nm)  this  requires  an  inclination 
in  the  order  of  84  degrees. 

14.  The  coverage  obtained  is  a  swath 
whose  inside  edge  is  offset,  in  this 
design,  to  the  left  of  the  sub  orbital 
point  by  some  180  nm  and  it  is  307  nm 
wide.  This  is  the  area  that  can  be 
covered.  The  actual  coverage  on  any  one 
pass  is  less  and  varies  slightly  (decreas¬ 
ing  with  distance  from  the  sub  orbital 
point)  but  averages  155  nm.  Thus  one  of 
the  prime  considerations  is  which  part 

of  the  "potential"  coverage  area  will 
actually  be  looked  at  on  a  given  pass. 

Fcr  the  sake  of  simplicity  we  will 
initially  assume  that  all  passes  are 
looking  at  the  area  closest  to  the  sub¬ 
orbital  point. 

15.  In  order  to  examine  the  factors 
important  to  submarine  surveillance  it 
was  necessary  to  define  the  submarine's 
important  operating  parameters.  A  sub¬ 
merged  transit  from  North  Cape  to  53N  22W 
at  a  speed  of  approximately  5  knots  was 
selected  as  the  intended  target. 

40  degrees  N  latitude  was  arbitrarily 
selected  as  the  southern  limit  of  the 
coverage  area  principally  because  this 
appeared  to  include  the  major  areas  of 
surveillance  interest  while  still  being 
possible  to  cover  in  a  useful  number  of  ' 


days.  At  40N  the  edges  of  the  swath  are 
nearly  N-S  but  they  "spread"  to  encompass 
a  greater  number  of  degrees  of  longitude 
as  the  latitude  increases.  For  the 
descending  pass  the  area  of  coverage  is 
a  mirror  image  of  this.  The  next  step  was 
to  build  up  a  pattern  of  these  swaths 
which  gave  complete  coverage  of  the  area 
N  of  40N  in  the  minimum  number  of  days. 


16.  Altitude.  For  the  altitude  of 
interest  we  have  a  period  in  the  order  of 
110  min  which  means  approximately  13 
ascending  and  13  descending  passes  per 
day.  If  the  altitude  is  decreased 
slightly  thereby  decreasing  the  period, 
the  14th  pass  is  slightly  East  of  the 
first  one  because  the  earth  has  rotated 
somewhat  less  than  360  degrees  since  less 
than  a  day  has  elapsed.  Similarily  if 
the  altitude  is  increased,  the  period 
increases  and  the  fourteenth  pass  is 
slightly  West  of  the  first  because  more 
than  a  day  has  elapsed. 

17.  Thus  the  altitude  affects  both  the 
pattern  of  the  ascending  and  descending 
passes  and  at  what  rate  the  pattern 
shifts  East  or  West  each  day.  Since  our 
inclination  has  been  determined  by  the 
desired  swath  geometry  the  altitude  is 
the  only  remaining  parameter  we  may  adjust 
to  satisfy  these  two  independant  requir¬ 
ements. 

600  NM  Orbit 

18.  Swath  pattern.  One  possible 
altitude  for  this  situation  turns  out  to 
be  approx  600  nm.  At  this  altitude  each 
descending  pass  is  centered  between 
adjacent  ascending  passes.  The  separation 
between  centres  of  the  ascending  passes  is 
approximately  27  degrees  and  between 
adjacent  ascending  &  descending  passes 
approximately  135  degrees. 

19.  Swath  rotation.  This  altitude 
also  causes  the  pattern  to  shift  some 
10.2  degrees  East  per  day.  Thus  on  day 

2  each  ascending  pass  has  shifted  so  that 
it  is  immediately  adjacent  to  the  previous 
days  descending  pass.  The  easiest  way  to 
visualize  this  is  to  imagine  a  pattern  of 
26  spokes  spaced  13.5  degrees  apart 
radiating  outwards  from  the  North  Pole. 

For  this  case  the  net  effect  is  to  make 
it  appear  as  if  the  26  spokes  are  rotating 
westward  at  approximately  3.4  degrees/day. 
At  the  end  of  4  days  every  point  N  of 
40N  has  been  viewed  at  least  once.  The 
pattern  of  coverage  buildup  is  identical 
in  each  27  degree  sector  and  is  depicted 
for  one  sector  only  in  fig  3. 


Ill 


FIG  3 

600  NMI  ORBIT  -  1  SAT  ACTUAL  COVERAGE 


20.  This  spoke  analogy  holds  true 
for  any  surveillance  satellite  whose 
sensor  views  a  swath  of  limited  width 
and  whose  inclination  is  near  to  90 
degrees.  The  number  of  spokes,  their 
width  and  the  rate  at  which  they  rotate 
will  vary  with  the  sensor  type  and  the 
satellite's  altitude  but  the  basic 
characteristics  are  the  same.  Continuing 
this  analogy,  the  areas  between  the 
spokes,  which  are  not  covered,  are 
"blind  spots"  and  any  moving  target  that 
stays  between  spokes  will  remain  unde¬ 
tected.  Since  the  spokes  rotate  at  a 
constant  angular  velocity  (in  this  case 
3.4  degrees/day)  the  actual  speed 
required  to  stay  in  a  blind  spot  will 
vary  -  increasing  with  decreasing 
latitude.  As  will  be  shown  shortly  the 
rotation  rate  of  the  pattern  of  spokes  is 
very  significant  for  the  purposes  of  this 
paper. 

21.  Latitude  effects.  Since  each 
swath  covers  a  constant  width  on  the 
ground,  it  views  an  increasing  number  of 
degrees  of  longitude  as  its  latitude 
increases.  Since  it  is  possible  to  steer 
each  swath  within  the  total  potential 
coverage  area  of  that  pass,  there  comes 

a  latitude  when  it  is  possible  to  cover 
the  entire  27  degrees  with  only  6  swaths; 
i.e.  in  only  3  days.  Similar ily  there 
is  a  latitude  where  complete  coverage  is 
possible  every  two  days.  For  this  600  nm 
orbit  three  day  coverage  is  possible 
N  of  56  degrees  N  &  two  day  coverage 
H  of  JJ  degrees  N. 

22.  SAR  output.  Thus  with  this  one 
satellite  all  open  ocean  north  of  40N 
would  be  viewed  every  4  days,  north  of 
56N  every  3  days  and  north  of  68N  every 
2  days.  Further  we  will  get  an 


approximate  size  of  surface  vessels  and 
their  course.  It  is  also  possible  to  get 
an  approximation  of  surface  vessels' 
speed.  As  was  mentioned  earlier  data 
processing  assumes  that  none  of  the  relat¬ 
ive  motion  between  radar  and  target  is 
caused  by  the  target.  Thus  any  velocity 
of  the  target  radial  to  the  radar  introd¬ 
uces  an  additional  doppler  signal  which 
the  processor  (falsely)  interprets  as  a 
shift  in  position  of  the  target.  Since 
the  wake  is  stationary  it  is  not  offset. 
Knowing  the  heading  of  the  satellite  and 
ship  and  with  the  measured  offset  of  the 
ship  from  its  wake  it  is  possible  to 
determine  ship's  speed.  Finally  there  is 
some  promise  that  imaging  (identification) 
on  a  non-cooperative  basis  of  ships  down 
to  type  and  class  may  be  possible  using 
SAR. 

23.  Orbital  disadvantages.  The  largest 
disadvantage  to  this  orbit  is  the 
regularity  and  slowness  with  which  the 
coverage  pattern  (and  therefore  the 
"blind  spots"  between  spokes)  rotate 
westward.  Fig  3  depicts  time  in  days  on 
the  vertical  scale  versus  longitude  for 
one  27  degree  sector  at  4 ON.  The  shaded 
areas  are  the  indicated  width  of  longitude 
covered  on  a  given  day.  If  the  target 
maintains  a  speed  of  approximately  seven 
knots  (one  swath  width  per  day)  in  a 
westerly  direction  it  can  remain  undetect¬ 
ed  indefinitly.  Undetected  movement  in 

an  easterly  direction  is  also  simple  and 
the  permissible  speeds  more  varied, 
including  2,  7  and  20  knots. 

24.  Swath  switching.  Up  to  this  point 
we  have  assumed  that  the  radar  beam  was 
fixed  on  the  coverage  area  nearest  the 
sub-orbital  point.  In  fact  it  is 
steerable  and  using  this  we  can  improve 
the  chances  of  detection  by  having  the 
radar  look  at  either  the  near  half  or  the 
far  half  of  the  "potential"  coverage  area 
on  a  random  basis.  Figure  4  shows  the 
possible  coverage  area  versus  time.  Every 
time  a  target  crosses  one  of  these  shaded 
areas  it  has  a  .5  probability  of  being 
detected.  With  this  random  switching  of 
swaths  a  given  point  may  not  be  viewed  for 
longer  than  the  nominal  frequency  of 
coverage  jbut  as  a  target  crosses  the 
"possible", area  more  than  oace  his 
probability  of  remaining  undetected  falls 
rapidly. 


FIG  4 

600  NMI  ORBIT  -  1  SAT  POTENTIAL  COVERAGE 


25.  Note  that  it  is  still  possible 
to  transit  in  a  westerly  direction 
undetected  at  7  knots  but  more  precise 
speed  &  navigation  requirements  are 
imposed.  The  effect  on  easterly  movem¬ 
ent  is  similar.  These  coverage  charact¬ 
eristics  are  for  latitude  40N  but  the 
salient  points  remain  unchanged  up  to 
latitude  56N  at  which  point  the 
"spreading"  of  the  swaths  gives  an 
overlap  of  the  possible  coverage  areas 
making  assured  undetected  movement 
impossible.  The  best  route  to  avoid 
detection  is  the  same  but  the  probability 
of  detection  is  now  .5  every  two  days. 

(ie  the  target  must  cross  a  possible 
coverage  area  once  every  two  days) . 

26.  Thus  the  coverage  provided  by  this 
orbit,  while  imposing  restrictions  on  a 
target's  movement  and  limiting  his 
tactical  freedom,  can  be  evaded  at  lower 
latitudes. 


27.  Tracking.  Once  a  target  was 
detected  and  if there  was  a  requirement 
for  increased  surveillance  this  could  be 
accomplished  by  having  every  satellite 
pass  within  range  adjust  it's  swath  to 
cover  the  expected  position  of  the  target. 
Unfortunately  the  time  of  the  next 
available  pass  is  very  dependant  on  the 
targets  position  within  the  pattern 
varying  from  12  to  108  hours  later.  This 
would  make  the  quality  of  tracking  extrem¬ 
ely  unpredictable. 


Data  Processing  and  Communications. 


28.  A  SAR  generates  very  high  data 
rates;  in  the  order  of  120  million 
bi£s/sec.  Up  to  the  present  all  of  the 
processing  for  SARs  has  been  done  on  the 
ground  in  non-real  time.  Any  system  for 


ocean  surveillance  would  have  to  be  real 
time  to  be  of  operational  use  due  to  the 
highly  perishable  nature  of  the  informat¬ 
ion.  To  illustrate  consider  a  submarine 
target  with  a  speed  of  five  knots.  If  we 
wish  to  localize  using  a  maritime  patrol 
aircraft  we  have  to  bear  in  mind  that  the 
MPA's  typical  search  area  resembles  a 
rectangle,  60  NM  wide  and  120  NM  long. 

If  the  target  makes  a  radical  course 
alteration  after  detection  he  could  be 
out  of  the  aircraft's  search  area  in  six 
hours.  Even  if  he  took  no  evasive  action 
he  would  be  out  of  the  search  area  in 
12  hours.  By  this  time  the  SAR  informat¬ 
ion  has  lost  much  of  its  tactical  value. 

29.  Processing.  Given  that  real  time 
processing  is  required  there  is  an 
inherent  tradeoff  between  the  amount  of 
processing  done  on  the  satellite  and  the 
bandwidth  (plus  complexity)  required  of 
the  satellite's  communication  system.  Any 
processing  done  on  the  satellite  would 
reduce  the  demands  on  the  communications 
system  (i.e.  lighter,  less  expensive, 
lower  power,  fewer  spectrum  management 
problems) .  Against  this  is  balanced  the 
weight  of  the  on-board  processor,  which 

at  present  is  prohibitive,  as  well  as  the 
risks  involved  in  an  untended  processor 
and  the  difficulties  in  splitting  up  the 
processing  sequence.  There  is  also  the 
question  of  flexibility  (i.e.  will  we  wish 
to  change  the  processing  algorithm?)  and 
susceptibility  to  seduction  (enemy  capture 
of  the  satellite  control  and  its  on-board 
functions) .  These  are  some  of  the  factors 
to  be  considered  when  looking  at  the 
processing/communications  configuration . 

30.  Communications .  There  are  three 
possibilities  as  to  how  the  data  (at 
whatever  stage  of  processing)  would  be 
transferred  from  the  satellite.  First  it 
could  be  relayed  via  communications 
satellites  to  a  facility  in  Canada.  The 
capacity  required  on  the  comsats  would 
depend  on  the  previous  question  of 
processing  configuration  but  the  SAR 
satellite  would  have  to  be  able  to  track 
its  relays. 

31.  Secondly  the  satellite  could 
record  its  data  and  play  it  back  when  in 
range  of  the  Canadian  ground  station. 

The  great  disadvantage  here  would  be  the 
delay  before  the  satellite  would  be  in 
range  of  the  ground  station  and  processing 
could  start  (approx  100  minutes  max) . 

Also  recorders  with  high  capacity  at 
present  have  poor  reliability. 

32.  The  third  option  would  be  setting 
up  multiple  ground  stations  so  that  the 
SAR  satellite  would  always  be  in  view  of 
at  least  one  when  it  was  viewing  an  area 
of  interest  and  thus  be  able  to  transmit 
its  data  directly.  These  ground  stations 
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would  conduct/complete  the  processing  of 
the  data,  sending  only  filtered  tracks 
to  the  central  facility.  The  number  of 
ground  stations  would  be  dependant  on  the 
size  of  the  desired  coverage  area.  To 
be  able  to  get  real  time  information  for 
everywhere  north  of  40N  would  require 
five  ground  stations  of  which  3  would 
be  outside  Canada.  For  this  method  the 
problem  is  the  cost  of  multiple  ground 
stations  and  the  problems  involved  in 
locating  them  on  foreign  soil. 

Power  Considerations 

33.  The  power  requirements  for  this 
orbit  are  more  extensive  than  RadarSat ' s 
primarily  because  the  greater  satellite 
altitude  necessitates  greater  radar 
power.  The  radar  will  radiate  when  it 
over  open  ocean  between  40  and  75N.  The 
solar  array  must  be  sufficient  to 
provide : 

a.  radar  power  plus  housekeeping 
or 

b.  housekeeping  power  plus 
charge  to  the  batteries 
sufficient  for: 


(1)  radar  operation  for  one 
eclipsed  40  to  75N 
transit  plus 

(2)  housekeeping  power  for 
the  longest  possible 
eclipse. 

34.  For  this  600  NM  orbit  a  40  to 
75N  transit  takes  .102  of  the  period  and 
the  longest  eclipse  is  .324  of  the 
period.  Thus  the  charging  requirement 
is  .178  radar  power  plus  .564  housekeep¬ 
ing  power.  Since  radar  power  is  an  order 
of  magnitude  larger  than  housekeeping 
power  the  power  requirement  at  b.  above 
is  smaller  than  at  a.  Therefore  the 
duty  cycle  described  here  (2  x  .102  or 
20.4%)  could  be  increased  without 
enlarging  the  power  supply.  Battery 
capacity  would  limit  how  much  of  that 
increase  could  be  during  the  eclipse. 

35.  The  useful  battery  capacity 
required  for  a  20.4%  duty  cycle  is  .102R 
x  P  plus  .324H  x  P  where  R  is  radar 
average  power,  H  housekeeping  power  and 
P  the  period  in  hours.  This  is  equal  to 
.182R  plus  .582H  where  R  and  H  are  in 
W-hours.  These  power  and  battery 
requirements  are  end  of  life  minimums. 
Reserves  would  have  to  be  allocated  for 
failures  and  degradation  over  time. 


Submarine  Detection  Using 


36.  Assuming  SAR,  or  some  similar 
sensor,  can  detect  submerged  submarines 


it  could  be  possible  to  maintain  a  track 
of  all  submarines  at  sea  within  a 
designated  area.  The  size  of  the  area 
would  sepend  on  the  capability  of  the 
power  generation/storage  system.  The 
revisit  time  would  be  dependant  on  the 
number  of  satellites  deployed. 

600  NM  Orbit  -  One  Satellite 

37.  For  instance  using  only  a  single 
satellite  with  the  orbit  under  discussion 
it  would  not  be  possible  to  have  assured 
detection  of  submarines  South  of  56N  if 
they  were  willing  to  accept  the  necessary 
restrictions  on  their  speed  and  course. 
Thus  those  planning  and  executing  a 
submarine's  voyage  would  have  to  consider 
the  relative  effects  on  the  mission  of 
being  detected  or  accepting  these 
restrictions . 

38.  Detection  Probability.  As  an 
example  consider  a  submarine transiting 
from  North  Cape  through  the  Faroes-Iceland 
gap  to  position  53N22W  (i.e.  just  North 

of  the  main  trans-Atlantic  great  circle 
route)  and  wishing  to  have  the  least 
chance  of  being  detected.  Until  he 
reaches  56N  the  submarine  has  a  .5 
probability  of  being  detected  every  two 
days  if  he  follows  the  track  of  least 
detection  probability.  His  probability 
of  being  detected  is  solely  dependant  on 
how  long  he  takes  to  transit  this  area, 
i.e.  his  speed. 

39.  To  find  the  probability  of  non¬ 
detection  over  a  number  of  days  one 
multiplies  the  probability  over  a  single 
time  period  (two  days  in  this  case)  by 
itself  for  as  many  time  periods  as 
required.  Thus  at  five  knots  the  target 
will  spend  13  days  North  of  56N  and  his 
probability  of  non-detection  is  (.5)  13/2 
or  about  one  chance  in  90.  At  ten  knots 
this  rises  to  one  chance  in  9  and  at 
fifteen  knots  to  one  chance  in  four. 

Once  at  56N  the  submarine  can  enter  a 
"blind  spot”  and  complete  its  transit 
undetected. 

40.  Clearly  in  the  area  where  there 
is  no  blind  spot  a  submarine  is  faced 
with  the  dilemna  that  at  low  speeds  he 
is  most  vulnerable  to  detection  by  the 
SAR  -  equipped  satellite  while  at  higher 
speeds  he  is  increasingly  vulnerable  to 
passive  acoustic  methods.  Thus  to  an 
extent  these  two  systems  are  complement¬ 
ary.  It  should  also  be  borne  in  mind  that 
the  information  from  these  two  sensors 

is  different  in  nature.  The  SAR  would 
hypothetically  give  an  accurate  position 
and  course  but  no  speed  for  a  submerged 
submarine,  and  the  interval  between 
updates  is  significant  (hours  to  days 
depending  on  the  constellation  used) . 
Passive  acoustics  give  only  a  probability 
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area (up  to  thousands  of  square  miles 
in  extent)  and  an  approximate  speed  and 
course  but  continuous  contact  can  usually 
be  maintained.  The  problems  involved 
in  localizing  and  tracking  the  two  types 
of  contact  are  thus  quite  different. 

For  the  SAR,  time  late  on  datum  is 
critical  to  keep  the  search  area  within 
reasonable  size  but  if  achieved  rapid 
localization  is  possible. 

600  NM  Orbit  -  Two  satellites 

41.  As  mentioned  earlier  the  revisit 

time  is  primarily  dependant  on  the  number 
of  satellites  used.  If  we  employ  a 
constellation  of  two  satellites  using 
this  orbit  with  the  second  satellite 
offset  in  longitude  by  approximately 
6.8  degrees  from  the  first  there  is  a 
great  improvement  in  surveillance 
capability.  Fig  5  shows  a  time  versus 
longitude  plot  (at  40N)  of  the  possible 
coverage,  with  one  satellite's  passes 
indicated  by  diagonal  lines  and  the 
second's  by  cross-hatching.  There  is 
no  assured  means  of  evading  detection 
by  this  constellation  in  the  area  of 
interest.  Because  of  this  we  can  best 
assess  the  probability  of  detection  by 
assuming  that  on  any  given  day  the 
target  has  an  equal  chance  of  appearing 
in  any  one  of  the  eight  swath  widths 
within  a  27  degree  sector.  Since  seven 
out  of  eight  of  the  swath  widths  could 
be  viewed  each  day  and  there  is  one 
chance  j.n  two  of  a  "potential"  swath 
width  actually  being  looked  at  on  a 
given  day  the  probability  of  detection 
per  day  (at  40N)  is  7/8  x  .5  =  .438  and 
the  probability  of  non-detection  is 
therefore  .563.  By  the  same  process 
the  probability  of  non-detection  per 
day  at  56N  and  68N  are  .417  and  .125 
respectively. 

FIG  5 

600  NMI  ORBIT  -  2  SAT  POTENTIAL  COVERAGE 


42.  Detection  Probability.  Looking 
again  at  the  submarine  transiting  from 
North  Cape  to  53N  22W  and  assuming  his 
speed  to  be  five  knots  we  find  that  he 
spends  5  days  north  of  68N,  8  days 
between  56N  and  68N  and  2  days  between 

53  and  56N.  Thus  the  probability  that  he 
will  make  the  transit  undetected  is 
(.125)  5  x  (.417)  8  x  ( . 56 3) 2  or  virtually 
zero.  At  ten  knots  the  probability  rises 
to  approximately  one  chance  in  10,600 
and  at  15  knots  to  1  in  540.  Clearly  by 
adding  a  satellite  we  have  vastly 
increased  the  usefullness  of  the  constel¬ 
lation. 

43.  This  orbit  is  intended  only  a 
starting  point  for  thought  on  naval  uses 
of  surveillance  satellites.  The  assumpt¬ 
ions  of  area  and  frequency  of  coverage 
were  largely  arbitrary  and  driven  by  what 
the  Canadian  RadarSat  is  being  designed 
to  be  capable  of.  There  are  obvious 
disadvantages  for  the  one  satellite  case 
with  respect  to  probability  of  detection 
(particularily  south  of  56N)  and  ability 
to  increase  frequency  of  coverage  on  a 
given  area. 

44.  To  improve  on  these  it  was 
necessary  to  design  a  pattern  in  which 
the  ascending  and  descending  swaths  on 
every  day  were  immediately  adjacent  to 
each  other  giving  the  widest  continuous 
coverage  area  possible.  This  would  permit 
greater  predictability  in  tracking  (since 
position  within  a  sector  would  no  longer 
be  significant)  as  well  as  increasing  the 
speeds  of  the  "blind  spots"  to  unusable 
levels.  Finally  the  altitude  was  raised 
such  that  four  day  coverage  north  of  30N 
was  possible. 

780  NM  Orbit  -  One  Satellite 

45.  This  second  orbit  would  require 
certain  improvements  in  the  radar  power 
and  data  processing  rate  as  compared  to 
the  600NM  orbit  but  has  several  advantages. 
In  this  case  the  inclination  is  85  degrees 
and  the  altitude  some  780NM.  The  greater 
altitude  of  the  satellite  widens  the 
coverage  swath  to  some  360NM  of  which 
approximately  half  can  be  viewed  at  any 
one  time.  The  pattern  of  ascending  & 
descending  passes  is  shown  in  Fig  6.  Each 
descending  pass  is  immediately  to  the 

East  of  an  ascending  pass  and  the  seperat- 
ion  between  each  such  pair  of  coverage 
swaths  is  28.8  degrees.  The  whole  pattern 
"jumps"  west  14.4  degrees  per  day.  Note 
that  this  assumes  each  pass  is  looking 
at  that  section  of  the  potential  coverage 
area  nearest  the  sub  orbital  point.  Since 
the  ascending  pass  can  look  further  to  the 
West  and  the  descending  pass  further  to 
the  East  each  such  pair  has  a  potential 
coverage  area  approximately  720NM  wide. 
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FIG  7 

780  NMI  ORBIT  -  1  SAT  POTENTIAL  COVERAGE 


FIG  6 

•  780  NMI  ORBIT  -  1  SAT  ACTUAL  COVERAGE 


48.  Since  each  swath  is  wider  than 
in  the  previous  example  the  area  which 
can  be  completely  viewed  every  4  days 
extends  further  south.  Similarily  the 
latitudes  at  which  complete  coverage  is 
possible  every  three  days  and  two  days 
are  also  further  South.  The  actual 
latitudes  are: 


every 

4 

days 

3  ON  - 

SON 

every 

3 

days 

50N  - 

64N 

every 

2 

days 

64N  - 

78N 

47.  Coverage  Area .  Figure  6  is  a 

display  of  time  in  days  versus  longitu¬ 
dinal  coverage  of  the  swaths  for  the 
region  30-50N.  While  the  pattern 
repeats  itself  every  two  days  and 
appears  to  cover  only  half  the  area,  it 
must  be  borne  in  mind  that  this  shows 
all  the  swaths  at  their  closest  to  the 
sub-orbital  point.  Looking  at  their 
potential  coverage  area  (fig  7)  we  can 
see  that  everything  North  of  30N  will 
fall  within  it  every  two  days.  Thus  this 
orbit  has  the  advantage  that  it  is 
always  possible  to  look  at  any  given 
point  twice  as  often  as  the  nominal 
frequency.  This  has  obvious  potential 
for  tracking  a  target  after  initial 
detection  or  keeping  a  particular  area 
under  closer  surveillance. 


116 


48.  Detection  Probability.  The 
probability  of  detecting  a  target  using 
one  satellite  in  this  orbit  is  consider¬ 
ably  better  than  the  previous  one.  The 
only  blind  spots  with  this  orbit  rotate 
both  East  and  West  at  14.4  degrees  per 
day.  To  stay  in  one  of  these  the  target 
would  have  to  maintain  30  knots  in  the 
East-West  direction.  This  can  be 
discounted  as  unlikely  in  most  naval 
scenarios.  Using  the  same  assumptions 
as  previously  we  find  the  probability  of 
detection  per  day  to  be  .25  at  30N, 

.33  at  5 ON  and  .5  at  64N. 

49.  Recall  the  case  of  a  submarine 
transiting  from  North  Cape  and  passing 
between  Iceland  and  the  Faroes  to  arrive 
100NM  North  of  the  trans  Atlantic  great 
circle  route  at  position  53N  22W. 
Transiting  at  five  knots  he  will  spend 
eight  days  N  of  64N  and  7  days  between 
64  6  53N.  Thus  the  probability  of  his 
not  being  detected  while  transiting  is 
(.5)®  x  (.67)7  or  about  one  chance  in 
4200.  At  ten  knots  the  probability  rises 
to  ( . 5 ) 4  x  (.67)3-5,  about  1  chance  in  65, 
and  at  15  knots  to  about  1  chance  in 
sixteen. 

50.  The  disadvantages  to  this  orbit  as 
compared  to  the  previously  described  one 
are  that  since  it  is  operating  at  a  great¬ 
er  range  from  the  earth  its  radar  must  be 
approximately  220%  more  powerful  (and 
hence  its  power  supply  system  also)  and 
since  it  views  a  greater  area  the  raw  data 
rate  is  greater  by  some  10%,  necessitating 
higher  processing  capacity  to  stay  in  real 
time.  Also  being  at  a  higher  altitude  the 
satellite  is  in  an  area  of  higher 
radiation  and  requires  additional  harden¬ 
ing  against  this.  Against  these 


disadvantages  this  orbit  provides  a 
greater  frequency  of  coverage  over  a 
wide  area,  greater  probability  of 
detection  and  more  flexibility  in  the 
coverage  patterns. 

PART  III  -  CONCLUSIONS 

51.  Allies.  There  are  several  points 
of  a  general nature  which  apply  to  naval 
surveillance  using  satellites.  First 
any  satellite  surveillance  system  will 
lookat  everypoint  on  the  earth's  surface 
between  its  most  southerly  and  northerly 
excursions  (ie  it3  inclination)  on  a 
regular  basis.  Therefore  any  Canadian 
system  would  be  able  to  look  at  extensive 
areas  that  may  be  of  only  peripheral 
interest  to  Canada  but  of  significant 
interest  to  one  or  more  of  her  allies. 

In  the  particular  case  of  a  submarine 
surveillance  system  the  USA  would  be 
especially  interested  as  they  would 
probably  view  the  data  from  such  a 
Canadian  system  as  a  potential  danger 
to  their  nuclear  submarine  fleet, 
particularily  their  SSBNs.  They  will 
probably  wish  to  have  some  control  over 
the  security  of  the  information  and  this 
issue  will  likely  have  to  be  faced  early 
in  any  Canadian  project. 

52.  Other  Sensors.  Secondly  during 
work  on  this  paper  it  became  evident 
that  unless  large  constellations  of 
satellites  are  used  SAR,  or  any  sensor 
giving  similar  data,  would  supplement, 
not  replace,  existing  submarine 
surveillance  systems  due  to  the  relativ- 
ly  infrequent  revisit  times.  This  being 
the  case  the  orbit,  hardware  and  process- 
i/ig  for  any  satellite  system  must  be 
designed  taking  into  account  this  need 

to  act  in  conjunction  with  more 
conventional  surveillance  systems 
including  acoustic  ones.  The  principal 
operational  question  is  how  best  to 
organize  the  satellite  constellation  to 
produce  data  which  effectively  complem¬ 
ents  information  from  other  sources. 
Relating  to  both  the  previously  mentioned 
points  is  the  fact  that  the  USA  controls 
precisely  those  sources  of  information 
(ie  large  area  submarine  surveillance) 
most  needed  to  complement  a  satellite 
constellation.  Therefore  there  is  an 
argument  to  be  made  that  both  the  US 
would  want  and  Canada  would  need  American 
participation  in  such  a  system. 

53.  Design  Questions.  There  are  a 
number  of  questions  which  effect  the 
orbit  which  must  be  answered  early  in  any 
design  process.  Among  these,  what  is 
the  expected  target's  speed?  (ie  what 
blind  spot  rotation  rate  is  needed?) . 

Hcrtt  great  is  the  need  to  be  able  to  track 
a  target  on  a  regular  basis?  What  is 


the  maximum  nominal  revisit  time  allowable 
bearing  in  mind  that  for  a  given  orbit 
this  will  vary  inversly  with  latitude? 

Is  there  an  area  (ie  latitude)  of 
particular  importance?  These  will  all 
drive  the  orbit  design  which  should  in 
turn  drive  hardware  and  processing 
considerations . 

54 .  Finally  the  raw  radar  information 

from  a  SAR  can  be  processed  in  various 
ways  depending  on  the  type  of  target  being 
sought.  This  will  probably  be  true  of 
any  sensor  used.  Thus  the  same  raw  data 
can  be  manipulated  for  different  purposes, 
both  military  and  civilian,  making  SAR  an 
inherently  multi-purpose  sensor.  For  a 
Canadian  system  this  presents  advantages 
in  that  costs  could  be  shared  to  same 
extent  with  a  non-DND  agency  or  agencies. 
Compromises  might  have  to  be  made  with 
respect  to  orbit  but  there  is  the 
possibility  that  the  security  sensitive 
hardware,  procedures  and  output  could  be 
confined  to  a  completely  seperate 
military  ground  processing  facility 
thereby  largely  sidestepping  the  problem 
of  compromising  classified  information 
due  to  civilian  involvement. 


117 


AD  P002159 


< 


DYNAMIC  SPACECRAFT  SIMULATORS  IN  MILITARY  SPACE  GROUND  SYSTEMS 

Robert  S.  Smith  III,  Phil  Davis,  David  A.  Goodwin 


i 

i 

i 


0A0  Corporation 
7500  Greenway  Center 
Greenbelt,  Maryland  20770 


ABSTRACT 

Simulators  have  long  been  used  in  training  situa¬ 
tions  to  provide  hands-on  experience  without 
risking  expensive  real  systems.  The  most  coamon 
example  is  in  aircraft  flight  training.  It  has 
been  0A0  Corporation's  experience  that  the  same 
principles  can  be  applied  on  a  much  more  modest 
scale  to  expedite  spacecraft  ground  system  inte¬ 
gration  and  operator  training. 

The  purpose  of  this  paper  is  to  outline  some  of 
the  uses  of  simulators  in  the  military  space 
ground  system  environment,  present  some  indica¬ 
tors  which  aid  in  determining  when  a  simulator 
can  be  beneficial  and  illustr^e  features  of 
appropriate  simulator  design.  -Wfe  validate  these 
points  by  drawing  on  six  years  experience  in 
providing  space  vehicle  and  operational  simula¬ 
tion  aids  to  NASA,  USAF  and  commercial  satellite 
control  centers,  f — - 

I.  INTRODUCTION 

The  dynamic  spacecraft  simulator  Is  a  mature  yet 
flexible  concept  which  has  been  utilized  In  a 
wide  range  of  NASA  and  DOD  programs.  Spacecraft 
simulators  are  highly  regarded  in  all  of  their 
applications  and  can  be  adapted  to  the  needs  of 
any  spaceflight  program.  The  remainder  of  this 
paper  presents  a  detailed  description  of  OAO 
Corporation's  approach  to  simulator  design  and 
applications  and  discusses  the  ease  with  which 
the  spacecraft  simulator  requirements  can  be 
defined. 

II.  SIMULATOR  APPLICATIONS  AND  BENEFITS 

A  dynamic  spacecraft  simulator  Is  an  optimal 
mechanism  for  exercising  ground  based  activities 
and  can  represent  a  demonstrable  cost  savings 
over  the  course  of  a  mission.  Some  of  the  more 
salient  applications  Include: 

•  Training 

•  Operations/data  base  validation 

•  Contingency  planning/workaround 

development 

•  Mission  rehearsals 

e  Pre-launch  checkout/validation 

e  Software  checkout/qualification 


Each  of  these  simulator  functions  is  described 
in  more  detail  in  the  following  paragraphs. 

As  a  trainer,  the  spacecraft  simulator  can 
provide  valid  replication  of  real  spacecraft 
performance  with  student  interaction,  yet  it 
totally  insulates  the  live  vehicle  from 
inadvertant  contact  with  training  operations. 
Further,  for  a  new  spacecraft  design,  it 
provides  the  only  means  for  this  level  of  on- 
the-job-training  (OJT)  prior  to  launch.  The 
simulator  also  provides  an  ideal  tool  for 
testing  operator  contingency  proficiency. 
Expected  or  predicted  anomalies  can  be  synthe¬ 
sized  and  repeated.  It  can  also  be  used  in  the 
certification/recertification  of  operators  and 
in  more  effective  OJT.  Finally,  should  the 
operational  environment  change  due  to  space¬ 
craft  changes,  equipment  degradation  or 
failure,  for  example,  the  simulator  offers  a 
unique  and  efficient  method  of  implementing 
real-time  training. 

Another  application  of  a  spacecraft  simulation 
is  the  validation  of  operations  and  data  base 
software.  Parameters  such  as  operations  language 
procedures,  display  formats,  and  data  base 
values  can  be  verified  as  accurate  prior  to  use 
in  real-time  operations.  Moreover,  non-nomlnal 
paths  in  operations  language  procedures, 
especially  those  responsible  for  alarm  messages 
and  emergency  mode  reporting,  can  be  exercised 
and  validated. 

In  contingency  situations  the  dynamic  space¬ 
craft  simulator  has  proven  indispensable  in 
anomaly  analysis  and  recovery  planning.  During 
anomalous  conditions  the  simulator  can  re¬ 
create  observed  problems  and  test  and  evaluate 
workarounds.  It  can  also  be  used  to  assess 
controller  responses  in  terms  of  accuracy  and 
swiftness  of  action.  In  the  critical  moments  of 
spacecraft  emergency  conditions,  the  simulator 
offers  the  opportunity  to  examine  the  impact  and 
implications  of  a  correcting  maneuver  without 
endangering  the  health  and  safety  of  a  live 
spacecraft  or,  ultimately,  losing  the  vehicle 
entirely.  NASA's  TIROS-N  controllers,  trained 
on  a  dynamic  simulator  were  able  to  contend  with 
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an  early  orbit  sudden  hydrazine  leak  as  well  as 
later  on-board  computer  (OBC)  anomalies  while 
preserving  both  on-orbit  test  schedules  and 
maintaining  delivery  of  payload  products. 

A  natural  extension  of  the  training  and  contin¬ 
gency  simulation  capabilities  is  the  rehearsal  of 
mission  requirements  since  both  normal  and 
anomalous  conditions  can  be  easily  replicated. 
This  can  be  especially  beneficial  for  critical 
launch  pad  testing  which  is  often  extremely  time 
limited.  Further,  a  launch  handover  operation  is 
a  very  singular  operational  activity  for  which  a 
simulator  provides  an  efficient  and  economical 
means  of  training  and  rehearsing  by  stimulating 
resident  data  base  parameters. 

Finally,  ground  system  software  which  partici¬ 
pates  in  the  same  environment  with  the  simulator 
can  effectively  be  qualified  since  it  can  easily 
provide  or  generate: 

•  Nominal  data 

•  Unique  application  data 

•  Perturbed  data 

•  Test  patterns 

Stress  testing  of  ground  system  software  is 
easily  provided  by  a  simple  extension  of  the 
simulator  capabilities.  Utilization  of  OAO 
Corporation's  Defense  Meteorological  Satellite 
Program  (DMSP)  Block  5D-2  Simulator  by  the  Air 
Force  resulted  in  shortening  the  ground  system 
Integration  cycle  and  cut  crew  training  time  by 
more  than  half  while  maintaining  proficiency. 

Inherent  to  the  applications  of  a  spacecraft 
simulator  are  significant  benefits  to  the  opera¬ 
tional  environment  of  the  mission.  Some  of  the 
more  salient  benefits  Include: 

a  Increased  reliability  of  the  con¬ 
trollers 

•  Increased  efficiency  of  the  control¬ 
lers 

o  Maximized  utilization  of  operational 

resources 

•  A  resident  Integration  validation  and 
verification  ( IV&V) 

capability 

•  Possible  extension  of  spacecraft  life 
through  anomalous  conditions 

Although  a  dynamic  Space  Vehicle  (SV)  simulator 
is  not  the  only  tool  available  for  some  of  the 
previously  mentioned  applications,  it  offers 
substantial  advantages  over  the  other  options  as 
indicated  in  figure  1. 

The  tape  replay  refers  to  digital  recordings  of 
actual  spacecraft  data  played  through  appropri¬ 
ate  elements  of  the  ground  system.  One  major 
drawback  of  this  approach  is  the  need  for  an 
operational  spacecraft  system.  The  scenario 
generator  on  the  other  hand  has  very  limited 
application  and  allows  little  if  any  dynamic 
capability. 
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Figure  1.  Comparison  of  Simulation  Tools 


III.  THE  SIMULATOR 
ARCHITECTURE 

The  generic  OAO  Corporation  simulator  architec¬ 
ture  is  illustrated  in  figure  2.  As  repre¬ 
sented,  simulation  software  is  executed  in  a 
host  processing  system.  Standard  interfaces 
provide  access  to  high-speed  disk  storage, 
magnetic  tape  storage  (for  disk  back-up  and 
canned  simulation  scenario  support),  a  line 
printer  (for  hard-copy  telemetry  and  command 
records  used  in  off-line  analysis),  and  the 
simulator  control  and  display.  In  general,  a 
simulator  can  be  run  either  in  an  off-line  or 
on-line  configuration.  The  off-line  system  is 
useful  for  debugging  and  testing  purposes.  It 
may  run  in  a  real-time  or  non  real-time  mode. 
Simulator  control  is  from  the  Simulation 
Director's  console.  The  on-line  system  runs  in 
real  time  and  is  generally  used  with  some  sort 
of  graphics  capabilities.  The  OAO  simulator 
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accepts  commands,  processes  them,  and  produces 
realistic  telemetry  from  the  various  spacecraft 
subsystems.  In  the  normal,  on-line  mode  of 
operation,  the  simulator  receives  commands  from 
and  delivers  telemetry  to  an  Operations  Control 
Center  (OCC).  Intermediate  output  and  telemetry 
can  also  be  routed  to  the  printer.  The  simula¬ 
tion  process  is  data  base  driven  and  is  dynami¬ 
cally  updated. 


■Ml  CM  MM 


Figure  2.  Spacecraft  Simulator  Concept 


The  simulator  software  structure  is  shown  in 
figure  3.  The  basic  software  modules  consist  of 
an  executive  which  provides  simulation  control, 
operator  interface,  and  initialization;  a  data 
base  containing  all  simulation  parameters  and 
files;  and  the  various  spacecraft  subsystem 
models  including  thermal,  power,  telemetry  and 
command,  orbit  and  attitude  control,  and  space¬ 
craft  state  and  environment.  The  relationship 
of  these  software  modules  with  the  host  system 
and  each  other  is  represented  in  figure  4.  Each 
of  these  modules  is  described  further  in  the 
following  paragraphs. 
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Figure  3.  Spacecraft  Simulator  Software 
Structure 
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Figure  4.  Dynamic  Modeling  Architecture 


The  Executive  Subsystem 

The  executive  is  typically  one  of  the  more 
sophisticated  subsystems  in  a  simulator.  Func¬ 
tionally,  the  executive  controls  the  scheduling 
of  the  tasks  through  three  phases:  initializa¬ 
tion,  execution,  and  termination.  During  the 
initialization  phase,  user-supplied  parameters 
are  read  in  and  used  to  set  up  the  initial  con¬ 
figuration  of  a  simulation  run.  This  initial 
configuration  can  be  changed  during  the  course 
of  a  run  by  operator  intervention.  Otherwise, 
the  initial  conditions  remain  in  effect  through¬ 
out  the  run. 

The  initial  conditions  include  selecting  an  on¬ 
line  or  off-line  run,  a  real-time  or  nonreal¬ 
time  run,  and  other  features  to  be  included  such 
as  graphics,  plotting,  checkpointing,  and 
refreshing. 

During  initialization  each  routine  selected  is 
executed  once  to  perform  any  initialization 
necessary.  When  the  execution  phase  is  entered, 
the  simulator  continues  cycling  until  the  desired 
stop  time  is  reached  or  until  a  stop  command  is 
entered  from  a  control  console. 

All  routines  are  executed  once  more  in  the  termi¬ 
nation  phase  to  give  each  a  chance  to  close  down. 
During  the  termination  phase  a  call  count  summary 
is  usually  printed  showing  how  many  times  each 
routine  was  executed.  A  log  sometimes  is 
produced  showing  any  timing  problems  that 
occurred  during  the  run  and  any  error  messages 
that  developed  are  also  printed. 

During  the  execution  phase  the  simulator  can  be 
in  either  one  of  two  modes,  normal  or  idle. 
Either  mode  can  be  specified  as  the  initial  mode 
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of  the  simulation  run.  During  the  normal  mode 
the  simulator  begins  cycling,  the  simulation  time 
advances,  and  all  modeling  and  coumunication 
routines  are  called.  Idle  mode  is  used  to  tempo¬ 
rarily  stop  the  simulator,  update  any  parameters 
desired,  and  then  allow  the  simulator  to  continue 
with  a  new  set  of  conditions  in  the  normal  mode. 
During  the  idle  mode  only  the  communications 
routines  are  executing.  The  simulation  t’me  is 
stopped.  Commands  continue  to  be  received  and 
executed  and  telemetry  is  fabricated  and  trans¬ 
mitted.  This  allows  the  user  to  modify  space¬ 
craft  conditions  by  changing  simulator 
variables. 

The  functional  flow  of  the  executive  subsystem  is 
characterized  in  figure  5. 
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Figure  6.  Spacecraft  Modeling  Overview 


Table  1.  Typical  Spacecraft  Subsystem  Model 
Parameters 


•  The  level  of  fidelity 

•  Timing  trade-offs 

•  Implementation  approach 

•  Hardware/software  trade-offs 


Each  of  these  considerations  are  discussed 
below. 


The  issue  of  model  fidelity  is  critical  to  the 
applicability  of  the  simulator  for  its  various 
uses.  It  appears  as  a  trade  issue  in  that  the 
degree  of  fidelity  will  greatly  affect  the 
necessary  analysis,  model  complexity/size,  and 
timing,  which  of  course  influence  cost, 
schedule,  and  choice  of  host  computer.  A  syste¬ 
matic  approach  to  accurately  determining  the 
fidelity  level  for  each  model  begins  with 
identifying  the  simulator  characteristics  and 
outputs  subject  to  variable  fidelity.  Next,  the 
simulator  requirements  are  analyzed  with 
respect  to  fidelity  level,  and,  finally,  simula¬ 
tor  models  are  qualified  according  to  fidelity 
level. 


0A0  partitions  its  models  into  four  levels.  The 
simplest  is  the  static  model  (level  1)  in  which 
a  user  may  select  values  for  different  telemetry 
points  which  remain  constant  throughout  the 
simulation  time.  More  complex  is  a  bilevel 
model  (level  2)  consisting  of  user-selected 
values  based  on  the  spacecraft's  condition 
(e.g.,  dark/light)  and  equipment  status  (e.g., 
on/off).  Increasing  in  complexity,  level  3  is 
an  equation  solver  or  function  generator  with 
which  the  user  selects  varying  values  for 
different  telemetry  points.  For  example,  solar 
array  temperature  can  have  two  values  (bi-level) 
depending  on  dark  and  light  conditions.  Or,  it 
can  be  modeled  as  level  3,  where  solar  array 
temperature  will  rise  exponentially  between  two 
temperatures,  depending  on  the  spacecraft's 
condition.  Level  4  is  the  most  complicated,  and 
Is  the  dynamic  model.  It  represents  interactive 
real-time  computed  values  Individually  modeled 
in  different  modules,  and  is  the  product  of 
several  Inputs  (spacecraft's  position,  solar 
array  position,  total  power  consumptions, 
etc.).  All  of  the  telemetry  points  usually  fall 
in  one  of  these  four  categories.  Table  2 
summarizes  the  modeling  classifications. 


Table  2.  Modeling  Classifications 

LEVEL  DESCRIPTION 

1  STATIC:  SELECTED  PARAMETER  VALUES  NHICH  REMAIN 

CONSTANT  THROUGHOUT  A  SINULATION 

2  BILEVEL:  DISCRETE  OR  ANALOG  VALUES  VHICH  ALLON  BINARY 

DECISIONS  (t-B-.  ON/OEF,  LIGHT /DARK ,  0/1.  ETC.) 


An  important  fidelity  issue  is  the  accuracy  of 
the  dynamic  models.  These  models  are  always 
analytic  in  nature,  make  use  of  implicit  or 
explicit  integration  ( i . e . ,  are  from  solutions 
of  differential  equations  or  require  minimal 
integration),  and  show  variation  at  system 
bandpass  or  higher  frequency.  Thus,  the  model 
implementation  represents  serious  implications 
for  core  and  cycle  time. 

It  is  necessary  to  always  considers  the  degree 
of  accuracy  needed  for  these  models  in  terms  of 
their  use  in  training,  software  validation,  and 
post  launch  anomaly  investigation.  Each  of 
these  respectively,  usually  require  a  more 
sophisticated  model  run  at  higher  cycle  frequen¬ 
cies.  0A0  establishes  model  complexity  in  terms 
of  core  and  percentage  of  computer  time  per 
eye  1 e . 


Timing  Considerations 


The  generation  of  simulation  time  and  its  rela¬ 
tion  to  real  time,  as  understood  by  the  ground 
system,  is  always  a  key  issue.  The  issue  is  the 
consistency  of  time  within  the  simulator  and 
between  the  simulator  and  the  ground  system. 


In  general,  the  simulator  time  will  not  be  actual 
time  due  to  training-specific  situations  and  the 
use  of  checkpointing  and  refreshing.  Neverthe¬ 
less,  the  simulator  time,  as  understood  by  the 
ground  must  maintain  internal  consistency  with 
the  ephermeris  and  spacecraft  clock. 


Cementation  Approach 


The  salient  implementation  approach  considera¬ 
tions  include  a)  what  ground  system  interfaces 
will  be  necessary  and  in  what  way  should  they  be 
represented  (i.e.,  emulation  vs.  real),  b) 
whether  the  simulator  shares  a  host  with  other 
processing  functions  or  is  resident  in  its  own 
host,  and  c)  the  scope  of  the  simulated  applica¬ 
tion.  Each  of  these  issues  represents  some  trade 
Involving  software  development,  hardware  sizing, 
operational  timing,  and,  of  course,  cost.  In  the 
case  of  the  NASA  Solar  Maximum  Mission  (SMM) 
Simulator,  a  shared  host  (IBM  360/65)  with 
special  Interfaces  (PDP-11/10  and  a  DX-11  inter¬ 
face  unit)  and  peripherals  (interactive  graphics 
facility)  resulted  in  an  efficient  and  highly 
flexible  dynamic  simulator.  Similarly,  with 
NASA's  Landsat-D  Simulator  all  simulation  was 
performed  by  software.  At  the  other  end  of  the 
spectrum  is  the  Air  Force's  DMSP  Block  5D-2  Simu¬ 
lator  which  utilized  a  dedicated  host,  custom 
hardware  and  a  real  OBC  to  accomplish  the 
facility  objectives. 


3  EQUATION:  CONTINUOUS  RANGE  OF  PARAMETER  VALUES  OERIVEO 

FUJI  AN  EQUATION  (e.?.,  UKP,  STEF,  LOG,  ETC.) 

<  OTNANIC:  EMPLOYS  NUEERICAL  INTEGRATION  TECHNIQUES  ANO 

MULTIPLE  PARAMETERS  IN  PROVIDING  REAL. 

DYNAMIC  SIMULATIONS. 


Hardware/Software  Trades 

In  general  terms,  the  trade  between  hardware  and 
software  in  a  simulator  design  spans  a  spectrum 
of  a  total  hardware  Implementation  to  a  total 
software  simulator  with  a  relative  mix  of  each 
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V.  OPERATIONAL  STRATEGY 


falling  In  between.  Not  surprisingly,  the  two 
are  proportionally  related  since  software  scope 
Increases  as  the  amount  of  special  hardware 
decreases.  Table  3  qualitatively  compares  some 
of  the  characteristics  considered  in  hardware/ 
software  trades.  Figure  7  is  an  example  of  trade 
comparisons  generated  by  0A0  for  five  alterna¬ 
tives  in  the  Air  Force's  DMSP  Block  50-2  Flight 
Vehicle  Simulation  Facility  (FVSF). 


Table  3.  Sample  Hardware/Software  Trade 
Characteristics 


HARDWARE/ 


characteristic 

ALL  HARDWARE 

SOFTWARE  MIX 

ALL  SOFTWARE 

RELATIVE  FIDELITY 

HIGH 

HIGH 

MEDIUM 

HARDWARE  SCOPE 

HIGH 

MEDIUM 

LOW 

SOFTWARE  SCOPE 

LOW 

MEDIUM 

HIGH 

MAINTAINABILITY 

LOW 

HIGH 

HIGH 

OPERATION 

0IFF1CULT 

FAIRLY  SIMPLE 

SIMPLE 

ANOMALY  SIMULATION 

OIFFICUlT 

LIMITED 

SIMPLE 

RELATIVE  SIM  SPEED 

SLOW 

MEDIUM 

HIGH 

RELATIVE  COST 

HIGH 

MEDIUM 

LOW 

Operational  strategy  addresses  the  question  of 
how  the  simulator  will  be  used  and  what  special 
features  will  enhance  its  utility  in  the  ground 
system  over  the  life  of  a  mission.  Typically, 
simulators  grow  on  the  users  in  that  the  initial 
objectives  are  rapidly  fulfilled  and  new  capa¬ 
bilities  are  perceived  as  the  mission  develops. 
This  places  a  premium  on  user-friendly  operating 
concepts  and  on  automated  intialization  and 
support  utilities.  For  example,  consider  a 
typical  training  scenario. 

Prior  to  the  training  session,  the  simulation 
operator,  or  trainer,  would  construct  a  command 
schedule  defining  key  elements  of  the  session 
such  as  ephemeris,  initial  spacecraft  state  and 
equipment  status,  data  acquisition  times,  etc. 
He  does  this  with  the  simulator  in  a  stand  alone 
mode  and  by  building  on  existing  data  bases  and 
schedules.  When  the  session  is  run, the  simula¬ 
tor  operates  under  control  of  the  schedule  and 
responds  to  real  time  Inputs  from  the  ground 
system,  leaving  the  trainer  free  to  observe  and 
advise  the  students.  The  trainer  still  has 
access  to  the  schedule  and  the  simulator  data 
bases  so  he  can  insert  unplanned  anomalies  or 
take  checkpoint  data  throughout  the  session.  At 
the  end  of  a  session  the  new  checkpoints  can  be 
used  to  repeat  selected  portions  without 
requiring  the  entire  schedule  to  be  redone. 
Similarly,  the  history  data  can  be  played  back 
for  analysis  of  significant  items  or  to  serve  as 
an  illustration  of  a  specific  training  issue. 

Scenarios  such  as  this  can  also  be  postulated 
for  ground  system  validation,  anomaly  investi¬ 
gation  and  all  the  other  potential  uses  of  the 
simulator.  The  unifying  theme  is  that  the  simu¬ 
lator  is  intended  to  be  a  functional  representa¬ 
tion  of  the  orbiting  spacecraft. 


Simulators  can  operate  in  real  time  either  with 
Figure  7.  Hardware/Software  Trade  Comparisons  or  without  inputs  from  the  ground  system.  Real 

time  refers  to  events  that  are  supported  in  the 
proper  wall  clock  time  in  the  operational 
environment  rather  than  strict  logic  speed 
Each  of  these  Issues  however,  cannot  be  synchronism.  For  both  modes  of  operation, 

considered  individually  but,  rather,  there  is  an  telemetry  outputs  and  command  inputs  are 

interplay  between  the  various  factors.  For  provided  and  accepted,  respectively,  at  the  same 

example,  model  fidelity  may  require  a  host  core  rate  as  would  for  an  operational  spacecraft 

size  and  speed  which  would  influence  host  selec-  real-time  simulation), 

tion,  and  the  host  selection  in  turn  will 

influence  interface  design.  Stand  Alone  Operation 


All  issues  require,  therefore,  an  integrated 
review  before  a  preferred  solution  is  finally 
established. 


Simulators  also  usually  incorporate  the  capa¬ 
bility  to  operate  in  stand-alone  mode  without 
inputs  from  the  ground  system.  In  this  mode, 
the  simulator  system  consists  of  the  simulator 
host  computer  with  its  associated  peripherals 
and  special  hardware.  The  host  real-time  clock 
is  used  to  generate  the  interrupts  necessary  for 
real-time  cyclic  simulation  functions. 
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Commands  are  input  using  a  host  CRT  and  telemetry 
Is  available  for  display  on  a  host  CRT.  No 
connection  to  the  ground  system  is  necessary  for 
this  operational  mode. 

Schedule  Control 

Simulator  control  can  be  provided  by  the  use  of 
prepared  schedules.  These  schedules  consist  of 
commands  with  associated  time  tags  having  a 
nominal  0.5  second  granularity.  Schedule 
commands  can  be  either  simulator  control,  model 
parameter  modification  statements  or  spacecraft 
commands.  The  schedules  are  built  in  an  off-line 
mode  and  stored  on  disk  without  Interfering  with 
ground  system  operation.  The  method  of  a 
schedule  build  considers  the  ease  of  operator 
interaction.  During  a  simulation  run,  the 
schedules  may  be  called  from  the  disk  schedule 
file  and  activated  by  a  trainer  command.  These 
inputs  can  also  be  accepted  individually  from  the 
trainer  position  in  real-time. 


Checkpoint/Restart/Idle 


Checkpoint,  restart,  and  idle  are  extremely 
useful  capabilities  which  are  incorporated  into 
most  simulators.  A  checkpoint  is  the  saving  of 
current  facility  parameters  such  that  the  saved 
file  is  sufficient  to  restart  the  run  from  the 
time  the  checkpoint  was  taken.  The  effect  of  a 
checkpoint  operation  is  to  record  in  a  user- 
specified  file  a  complete  set  of  data  represent¬ 
ing  the  current  state  of  the  system.  As  a 
minimum,  this  data  Includes,  a)  the  system  data¬ 
base,  b)  the  names  of  all  the  data  files 
currently  supplying  data  to  the  system  (e.g., 
schedule  files),  and  the  current  read  position 
within  each  file,  c)  all  data  necessary  to 
completely  represent  the  state  of  each  model,  and 
d)  the  total  system  configuration  information. 
Time  is  halted  while  a  checkpoint  file  is  being 
created  or  reloaded  into  the  facility. 


Restart  is  initializing  the  facility  utilizing  a 
previously  stored  checkpoint  file.  In  particu¬ 
lar,  the  restart  action  Includes  a)  verifying, 
via  checksumming  or  similar  techniques,  the 
validity  of  the  checkpointed  data,  b)  restoring 
the  system  database  and  any  other  data  needed  to 
represent  the  state  of  each  model,  c)  Interacting 
with  the  system  operator  to  obtain  the  additional 
data  files  (schedule  files,  etc.)  that  are 
needed,  d)  initializing  I/O  logic  to  begin 
reading  at  the  proper  position  in  each  file,  and 
e)  verifying  that  the  system  configuration  Is  the 
same  as,  or  Is  compatible  with,  the  configuration 
on  which  the  checkpointed  data  was  generated. 


Idle  is  interrupting  the  flow  of  time  for  the 
purpose  of  examining  or  modifying  specific  data 
without  creating  a  checkpoint.  Analog  and 
digital  telmetry  flow  are  maintained  while  the 
facility  Is  in  Idle  mode,  but  the  data  values  are 

static. 


Another  important  capability  of  a  spacecraft 
simulator  is  to  provide  a  means  for  anomaly 
Injection.  Anomaly  injection  is  provided  under 
direct  control  of  the  trainer.  The  anomalies 
are  entered  directly  from  the  trainer  console, 
or  by  use  of  prepared  schedule  files.  The 
anomaly  injection  procedure  does  not  interfere 
with  the  real-time  update  of  simulated  data. 


Anomalies  usually  represent  one  of  three  types 
of  errors:  uplink  errors,  downlink  errors  and 
spacecraft  subsystem  anomalies.  The  uplink 
error  may  include  either  a  specified  bit  error 
rate  or  trapping  of  a  specified  command. 
Downlink  errors  may  be  either  incorrect  sync 
patterns,  incorrect  parity  words  or  the  complete 
loss  of  data.  The  spacecraft  subsystem 
anomalies  may  consist  of  subsystem  failures 
chosen  with  the  following  criteria  in  mind: 


t  Probabilistic  subsystem  failures  from 

prior  spacecraft  performance  data 

•  Anomalies  for  which  ground  system 
personnel  reactions  are  significant 

•  Anomalies  which  are  precursors  to  more 
serious  malfunctions 


Truth  Data 


Truth  data  is  often  accessible  to  the  simulator 
trainer  independent  of  the  telemetry  processing 
by  the  ground  system.  This  data  consists  of 
both  telemetry  data  and  non-telemetered 
parameters  which  are  of  importance  in  observing 
simulator  operation. 


Clock  Synchronization 


A  mechanism  is  usually  provided  in  the  simula¬ 
tion  facility  for  synchronizing  the  clocks  to 
that  of  the  ground  system.  During  a  real-time 
run,  all  time  dependent  processes  are  synchro¬ 
nized  to  within  one  nominal  time  update  step. 


A  valuable  capability  generally  provided  is  the 
ability  to  generate  a  history  tape  of  the 
telemetry  data  and  command  activity  during  simu¬ 
lation  operations. 


VI.  SUMMARY 


Spacecraft  dynamic  simulators  have  been  shown  to 
provide  many  benefits  to  military  space  ground 
systems.  Beneficial  applications  include 
training,  operations  validation,  contingency 
planning  and  workaround  development,  mission 
rehearsals  and  ground  system  checkout  and  quali¬ 
fication.  The  simulator  architecture  presented 
is  based  on  a  real-time  Implementation  of 
dynamic  closed-loop  spacecraft  and  environment 
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modeling.  An  approach  to  the  design  and  opera¬ 
tional  trade-offs  important  to  any  simulator 
implementation  was  presented,  including  a  level 
of  fidelity  analysis  methodology.  Finally, 
various  operational  strategy  Issues  were 
presented  and  discussed.  0A0  believes  that  a 
dynamic  space-craft  simulator  provides  a  valu¬ 
able  capability  for  military  space  ground  systems 
and  furthermore  can  provide  these  benefits  with  a 
positive  benefit/cost  ratio  over  typical  system 
life  cycles. 


